On Mon, Mar 3, 2008 at 1:41 PM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> We've talked about Buffet replacements before, but I've talked with a
> few people now about going a different route. Making it so easy to
> write your own 'render' function, that Buffet and such wouldn't even
> be necessary.
Bypassing Buffet would be nice; it would save me a ton of work in
upgrading it, and we'd be rid of those half-baked dotted-notation
entry-point-using plugins.
One thing Ian wanted was a generic template loader which could be
passed in to template engines for looking up included/inherited
templates. But since no template engine has a hook for a non-native
loader, I'm not excited about putting work into it. Giving Mako a
Mako loader and Genshi a Genshi loader makes more sense.
> Disadvantages:
> - It's a few more lines of code to plugin a template engine (About
> 5-10 lines of Python code, most of which can be copy/pasted)
We need to do something for people who want to use a different plugin
other than the one that's discovered via the entry point (if there is
an entry point), so this would take care of that.
> Advantages:
> - Powerful template language capabilities aren't smothered under a
> Template API
> - It's significantly easier to see how and where you'd configure
> specific options
> - It's easy to change template rendering for a specific app
> - It's easy to change global variables used in your app
> - More efficient, ie, less function calls
> I'm thinking that in new project templates, it will merely import
> render_mako as 'render'. If a user needs to tweak options for Mako,
> you can see from the render_mako where it looks for the Mako
> TemplateLoader, and easily make it yourself in app_globals. No config
> with prefix values all over being tossed around, no big Buffet objects
> holding onto who knows what (generally its imported every template
> engine it can).
Well, that would give an excuse for pylons.g to exist. But it's an
unusual place to do application configuration, which is normally in
load_environment().
One problem is you're combining data variables and rendering options
into the same 'kwargs' namespace, which we were trying to avoid.
Buffet 1 never specified whether keyword args were one or the other,
although I think the plugins use them only for rendering options. But
those who prefer @expose or render(template, var1="value 1") over
pylons.c would like passing data values as keyword args. Our plan for
Buffet 2 was:
render(template, data_dict, cache_bla_bla_bla=None, **rendering_args)
> Currently, I'm planning on having 0.9.7 new project templates use the
> render_mako function, while including a future deprecation warning for
> Buffet, with more blatent deprecation warnings in 0.9.8 as 1.0 will
> drop Buffet entirely.
Sounds good.
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
