> From: Christopher Lenz <cml...@gmx.de> > Date: June 29, 2007 12:10:54 PM GMT-04:00 > To: pytemplates <firstname.lastname@example.org> > Subject: Re: Pylons/TurboGears templating > Reply-To: email@example.com
> 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:
> 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