Fwd: Pylons/TurboGears templating

10 views
Skip to first unread message

Kevin Dangoor

unread,
Jun 29, 2007, 5:28:26 PM6/29/07
to turbogea...@googlegroups.com


Begin forwarded message:

From: Christopher Lenz <cml...@gmx.de>
Date: June 29, 2007 12:10:54 PM GMT-04:00
To: pytemplates <pytem...@googlegroups.com>
Subject: Re: Pylons/TurboGears templating


On 28 Jun., 00:10, "Mike Orr" <sluggos...@gmail.com> wrote:
DOTTED NAMING
==========
I'd rather drop this completely but I suspect there'll be howls of
protests from TurboGears users as well as Kid/Genshi users that are
accustomed to it. The naming system is what determines how a template
at /myapp/templates/foo/bar.html is identified in the application.
Assuming /myapp/templates is the base path or search path:

Path naming: foo/bar.html
URI naming: /foo/bar.html
Dotted naming: foo.bar

For the record, Genshi uses path names internally, and the dotted
naming support was only added in the plugin layer, and only to support
TurboGears. And as the Pylons Buffet implementation seems to only pass
through paths/URIs to Mako and Myghty, there hasn't been much
incentive to change to fix the plugin implementation.

Personally, I'd kill dotted naming support in a heartbeat. Genshi
certainly doesn't require it, and would rather just use path names.

Anyway, does Smorgasbord actually need to even care about this? Can't
it just pass through the name as-is?

OPTIONS
=====
The template options and rendering options ('encoding', 'fragment',
etc) are still in my head. Only the options necessary for template
lookup are implemented. I still think standard engine-neutral options
are the way to go for common stuff, but it will require further
research to finish the option handling.

Note that contrary to your Smorgasbord documentation, Genshi doesn't
actually support "fragment" (there's no need, as Genshi doesn't use an
inheritance scheme).
Does that make Kid (and possibly Myghty?) the only template engine
supporting "fragment"? Maybe it's not even worth standardizing in that
case?

Also, the difference between "template options" and "rendering
options" isn't clear to me. It looks like the former should be the
options passed to the engine when it is initialized, while the latter
are passed to render() but that doesn't seem to be the case.

On a more general note, I think the Smorgasbord API tries to be/do too
much. Why should it do template lookup and caching, rather than
leaving that up to the template engine, or to the framework or
application. Why define common options such as "exts" if you could
just leave the way the user references templates to the template
engine (plugin)? I think that ideally, the Buffet replacement should
be a very thin layer between the application and the template engine,
and not make the individual plugins jump through hoops to behave like
other engines do in some respect. IMHO, the goal shouldn't be to
enable people to instantly swap out template engines (that wouldn't
work anyway), it should be to enable web framework users to use the
template engine of their choosing, without limiting the feature set,
while still nicely integrated into the framework. Where "nicely
integrated" means it can be configured along with the rest of the
webapp config, is initialized with the rest of the framework, etc.

Genshi adds some aspects to this that most other engines don't.
Essentially, there isn't just a big "give me a filename and a dict, I
give you a string" step. Instead you have:
1. when a template is first loaded, you may want to add some filters
to it, such as for I18N. You need to make sure this is only done once
per template instance.
2. you then generate a "markup stream" (basically an unserialized
representation) from a template, passing it the data dictionary
3. you may then want to apply filters to that stream, for example for
HTML form population (think htmlfill without the reparse), or do
transformations such as adding CSRF protection to any POST forms, etc
etc
4. finally you serialize that stream to a string, using a specific
format, doctype, encoding, etc

The current Buffet API has a "transform()" function that (in theory*)
allows one to add stream filtering etc (i.e. point 3. above).
transform() is basically point 2, while render() was either points 2-4
or just point 4 (depending on whether you passed in a stream or a
template name). I guess the Genshi plugin for the new API could do all
this via a heavily overloaded render() function, but that'd be pretty
ugly.

* I say "in theory" because e.g. Pylons does not make that feature
conveniently accessible to applications, so it goes unused even for
Genshi-based apps

Cheers,
Chris
--





Reply all
Reply to author
Forward
0 new messages