On Wed, Mar 5, 2008 at 10:23 AM, Ben Bangert <[EMAIL PROTECTED]> wrote: > 0.9.7 project > # Create the Mako TemplateLookup > > config['pylons.g'].mako_lookup = TemplateLookup( > directories=paths['templates'], input_encoding='utf-8', > output_encoding='utf-8', module_directory=os.path.join( > app_conf['cache_dir'], 'templates'), > )
Hmm, Cheetah does not have a loader, so looking for templates in a certain directly would have to be provided by an external (function|class). But render_cheetah() could do that itself from config['pylons.paths']['templates']), and wouldn't need anything in pylons.g. Most of the other template engines would also be in this situation. > With regards to the templating system's API, including > TemplateProposal in Pylons would have the same effect to needing to > change when the template system changes if it has the renderer objects > in it. That was the only saving grace of Buffet, was that the template > system API could change, and its included Buffet adapter could change > with it. The plan was to release TemplateProposal (Buffet 2) as a separate package, so Pylons would just need some glue code to gather the options and present them, plus a render function/class (which Pylons has to provide due in order to inject the Pylons globals). The reason Buffet 1 was in Pylons was it needed a lot of customization to be compatible. -- 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 -~----------~----~----~----~------~----~------~--~---
