A Buffet replacement

[Ben Bangert]

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.

Disadvantages:



Advantages:

- 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


http://pylonshq.com/pasties/732







Any other thoughts?

Cheers,
Ben

- 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) - 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 I've include a render_mako and render_genshi function in pylons.templating, there's a paste of the relevant section here: 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). It's rather easy to document, and provide some sample render functions for other template languages used as well. I've included two helper functions for use with render_* functions, one that pulls the Pylons globals that should be included, and one that enables cache_* options to be used. 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.

smime.p7s
Description: S/MIME cryptographic signature