Ben Bangert wrote: > On Mar 4, 2008, at 9:36 PM, Ian Bicking wrote: > >> It's a rendering factory someone wrote. A little like Buffet, except no >> entry points, no standardized way to instantiate the object, and no >> particular need to make the render callable have a completely consistent >> signature. > > Yet another level of obfuscation and misunderstanding, and yet another > thing that will trip up those wanting to try and change how a template > language is configured. > >> Putting a 15-line recipe into the pylons template seems really scrappy. > > All of Pylons is a recipe. It's a recipe to configure Paste, a batch of > middleware, and do some dispatching with Routes. The entire thing is no > more scrappy than having a render function that uses the template engine.
Putting that code into Pylons is fine, but I think Pylons already has too much code in the project template, and your proposal puts more code in the project template. That code would need to be updated for any kind of public change in a templating system's API. > I don't see this MakoRenderer being any less or more scrappy than a > basic render function, but at least everyone I showed the render > function to is 100% aware of what it does, and how they could change it. > While MakoRenderer is another "what the heck is this? how come I can't > just configure the template engine?". MakoRenderer is more a suggestion that templating engines expose an API that is useful/friendly in the context of Pylons. A useful API for Mako (at least with respect to Pylons) is one where you configure a rendering instance, and then that rendering instance is callable like the current render() function. >> MakeRenderer seems simpler than this, with no recipe stuff stuck in >> there. > > I'm baffled that the hundreds of lines of code in the templateproposal, > the setuptools entry points, the plugin hooks, the limiting render calls > (which prevent you from accessing the Genshi stream object which some > ppl want...).... is simpler than a 7 line render function. Even with > TemplateProposal, 95% of the code I pasted is still needed in > pylons.templating because it handles cache functionality and populating > the template variables with the Pylons globals. I've written some > extensive docs and committed them regarding how to use the render > functions and write one: > http://pylonshq.com/project/pylonshq/browser/pylons/templating.py > > Let's ask the Pylons list, whether using this package: > http://svn.pythonpaste.org/Paste/TemplateProposal/branches/TemplateProposal-MSO/ > I agree that the entry point stuff and other aspects of that are overdesigned. It was inherited from Buffet (and somewhat motivated by paster create), but in the context of Pylons I agree there is no reason to use an entry point. MakoRenderer is a suggestion for how pylons.templating could work, making it more similar to how helpers works, and less tied into things like wsgiapp, pylons.config, etc. I do agree with your proposal in terms of moving the render function into projects directly, instead of importing it from Pylons. This makes ad hoc render functions obvious, and I'm not suggesting that ad hoc functions are bad. But there's no reason to make *every* render function ad hoc. Ian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
