Begin forwarded message:
> From: Christopher Lenz <[EMAIL PROTECTED]>
> Date: June 29, 2007 12:10:54 PM GMT-04:00
> To: pytemplates <[EMAIL PROTECTED]>
> Subject: Re: Pylons/TurboGears templating
> Reply-To: [EMAIL PROTECTED]
>
>
> On 28 Jun., 00:10, "Mike Orr" <[EMAIL PROTECTED]> 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
> --
> http://www.cmlenz.net/
>
>
> >
--
Kevin Dangoor
TurboGears
email: [EMAIL PROTECTED]
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
