Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #1942 (closed defect: fixed)

Opened 11 years ago

Last modified 11 years ago

New renderers do not support dotted notation

Reported by: mramm Owned by: mramm
Priority: highest Milestone: 2.0b1
Component: TurboGears Version: trunk
Severity: normal Keywords:

Description (last modified by mramm) (diff)

We don't support the old dotted notation for template lookup at all anymore for genshi. We probably need to add our own genshi template loader, and provide some level of backwards compatibility.

Change History

comment:1 Changed 11 years ago by mramm

  • Description modified (diff)

comment:2 Changed 11 years ago by mramm

  • Milestone changed from 1.9.7a4 to 2.0b1

comment:3 Changed 11 years ago by mramm

  • Owner changed from anonymous to faide

comment:4 Changed 11 years ago by faide

  • Status changed from new to assigned

Is this Genshi only or should we support this for other templating engines?

comment:5 Changed 11 years ago by mramm

I have not tried it, but from the code it looks like it may already work with mako templates. I think genshi is where we need the backwards compatibility, and I think we should change the docs to prefer the search path notation since that seems to be a standard that's been adopted by gehshi/mako/jinja,

comment:6 Changed 11 years ago by faide

I don't quite understand what you mean by search path, but I definitely want to implement a dotted path system for genshi and maybe others: this will open the road to zip safe distribution of TurboGears2 apps.

I have something nearly working for dotted names (python path) support for Genshi and I hope to commit that thingie tonight.

One point I'm not sure of is this: Should we have a config switch in that specifies the template search notation (ie: template_search=dotted/path) or should we have this in the template string (ie: @expose('genshi/dotted:myapp.templates.index'))

I would really prefer to use the config option to globally define the search system. This is what I will implement first.

Tell me what you think.

comment:7 Changed 11 years ago by mramm

I think a global configuration option is good, an I agree that it should be implemented first.

I /think/ mako's template loader handles both by default, so that would be another option I guess.

The big question is which should be the default:

    def something(self, **kw)

    def something(self, **kw)

I strongly support the first, and support using search paths to do lookup, because we can then configure Rum, or Tortuga or whatever to use the same master template just by adding it to the top of both search-paths. If we're going to start doing site-composition we need a simple way for people to share site-wide styling in a somewhat framework agnostic way, and this seems like one of the simplest solutions.

comment:8 Changed 11 years ago by faide

I see the point of the simpler no-dot-support-at-all, what I have at the moment is code that supports dotted notation with the new render functions system.

I'll have more questions that will rise from the code. (ie: template extension support)

I'll commit something in a few minutes/hours and we'll continue the discussion over some real life implementation to fix/strengthen... :)

comment:9 Changed 11 years ago by faide

I need one more info to before I push my code: do we already support the template names with engine prefixes in the @expose decorator ?

I don't see mention of that kind of notation in the documentation...

comment:10 Changed 11 years ago by mramm

You mean:


Yea, that should be supported now.

And it is mentioned in the API docs for expose, though it should definitely make it up to a higher level doc somewhere.

comment:11 Changed 11 years ago by faide

ok I'll make sure the code I commit supports this then. Thanks

comment:12 Changed 11 years ago by faide

Added support for dotted names in r5845

I have set the dotted names as the default for the moment because the simple names are not yet supported with simple renderer functions.

I need a first review and we can polish the thing up...

comment:13 Changed 11 years ago by faide

I have done a quick test with genshi and mako in the same project with template names prefixed by engine names and it works.

I also tested that template modifications are taken on the fly without needing to restart the server.

comment:14 Changed 11 years ago by mramm

  • Status changed from assigned to new
  • Owner changed from faide to mramm

Looks good to me. Assigning it to myself to do a real code-review.

comment:15 Changed 11 years ago by mramm

We need to add a few tests for this.

Also I have reports that the mako template lookup stuff is not working right with this new setup.

comment:16 Changed 11 years ago by mramm

added a couple tests in r5863 and r5864 -- looks from r5864 like mako inheritance lookup is broken by the current code.

Also, I personally think that we should still use the standard file-system lookups by default.

comment:17 Changed 11 years ago by mramm

Checkin r5864 turns those tests back to non-dotted to make sure the base mako stuff all worked prior to the new code -- we didn't have tests for that :(

We can add some new tests for dotted lookup.

comment:18 Changed 11 years ago by mramm

  • Status changed from new to closed
  • Resolution set to fixed

For the two core template engines (mako and genshi) this is completed, with tests. I will make a new jinja ticket.

comment:19 Changed 11 years ago by faide

Did we not have one more thing to do: support path based names with new renderers?

ATM we support fixed directory + TemplateLookup? & python module + DottedTemplateLookup?

should we add full pathname support ?

comment:20 Changed 11 years ago by mramm

Doesn't full pathname support come for free with the standard template lookup functions in mako and genshi?

It's just that we're setting the template path to the search-path in both cases. If you create subdirectories you'll see that there is support for relative paths.

comment:21 Changed 11 years ago by faide

Nice. This means we're just done with this ticket!

I'd like a confirmation that mako inheritance works well in real life with real users as I don't use mako and just did that reading the API documentation and wrote a simplistic test to atg least verify the basics, but a real project using mako confirming that dotted names work with inheritance would be nice.

Note: See TracTickets for help on using tickets.