On Mar 5, 2008, at 11:21 AM, Mike Orr wrote:
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.
Most of the ones I've seen have an option to give it a directory search path. In any case, the best way to encourage a template system author to have a sane API, is to actually *use it*. If we wipe away its issues under Buffet/TemplateProposal, they have little reason to make a solid and sane template loader/render API in the template system itself. Most of the time though, when a template system needs more configuration, its for a good reason, and the user generally wants to participate in ensuring the configuration meets their needs. At which point, exposing that to the user directly is ideal to avoid confusion and retain ease of use.
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.
Yea, thats exactly what I was afraid of. Yet another external dependency package to track. Ian's argument about template system API's also applies to tracking external TemplateRenderer packages, both may change requiring a change in Pylons. Pretty much anything not in Pylons itself, requires careful consideration to depend on as a new version of said external package may change causing integration issues. I know the TemplateProposal is supposed to be solid forever, but you can't account for all options for all, or even most template languages and hold out hope for stability any long than hoping they can at least keep their template loader mechanism mostly the same over revisions (which so far, they have).
At least with the render_ functions, if one of them breaks, and a project *needs* to use the latest template system before a new Pylons release can be issued, they can easily write their own render function.
Cheers, Ben
smime.p7s
Description: S/MIME cryptographic signature
