Re: A Buffet replacement

[Ben Bangert]

On Mar 5, 2008, at 9:20 AM, Ian Bicking wrote:

Putting that code into Pylons is fine, but I think Pylons already has

in the project template.  That code would need to be updated for any
kind of public change in a templating system's API.

too much code in the project template, and your proposal puts more code

0.9.6 projects
    # Customize templating options via this variable
    tmpl_options = config['buffet.template_options']

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'),
    )



If you're using Genshi, its actually a zero-sum trade:

    # Create the Genshi TemplateLoader

When you look at the existing template options being configured in the project template, replacing the config lines for the template with actually making the Mako TemplateLookup instance is a pretty close tradeoff. There's only 3 lines added, and the result is significantly more obvious. Consider these two, and tell me what the config options are for Mako in the first case: If you wanted to change the template engine options in the first case, how would you do it? What are the defaults it came with? I will happily accept a line or two of extra code for obviousness and ease of use/customization. config['pylons.g'].genshi_loader = TemplateLoader(paths['templates']) Also, you can't see this, but by having the template engine created here, I will get to drop about 100 lines of code from pylons.configuration and things are cleaner both for the user, and for Pylons. 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. How often do the templating system API's actually change though? Is that a strong argument for something that occurs frequently, or something thats once in a blue moon (which could also be screwed up by the existing pylons.configuration template system defaults)? So far, Mako's TemplateLookup has stayed the same for many revisions, and Genshi's is not changing in the next release either. But Pylons has always had code that generally depends on specific revisions of supporting packages. Mako and Genshi are both stable, fairly mature template systems, they're the only ones Pylons is including a render function for. In the worst case scenario, that a user should upgrade Mako/Genshi beyond a version Pylons recommends, and the template system API does change slightly, it will be trivial for the user to fix it (and of course a new Pylons version will address it as well). They can change the loader in their environment, and tweak the render function if needed. There is no waiting on a commit to the template system for an updating plugin, no waiting for a commit/release of a new Pylons as some default inside of Pylons might be screwing things up.

MakoRenderer is more a suggestion that templating engines expose an API

that is useful/friendly in the context of Pylons.


configure a rendering instance, and then that rendering instance is
callable like the current render() function.

A useful API for Mako (at least with respect to Pylons) is one where you

I think current template systems do have friendly API's. Look at how brief it is to do the basic template lookup creation, then render a template with either Genshi or Mako. It's downright trivial, and seriously makes you wonder what the hundreds of lines of code in TemplateProposal are supposed to 'simplify'. I'm am consistently seeing a trend where users prefer something obvious, even if its just a wee bit more verbose, for the sake of not being left with a big learning curve later when they want to change just one option in how something works. I should mention that I've had more than a few users ask me why they have to dive though a big ol Template/Buffet thing to change a few things about how a template system is used, when they can setup and use the template engine in 5 lines of code in CherryPy or Django. Saying, "In the very off chance that the template system API changes dramatically, its slightly easier!" is hardly a good response.

I agree that the entry point stuff and other aspects of that are
overdesigned.  It was inherited from Buffet (and somewhat motivated by

to use an entry point.

paster create), but in the context of Pylons I agree there is no reason

Though without the entry point scanning, I don't see how it'll be any better than what I wrote up, as it won't be able to find the appropriate render function automatically in installed template systems. At which point, its just like what I wrote up except more verbose.

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.

As Mike said, I'm curious what the point is for a class. It's not holding any state data, why not just the render function?

I do agree with your proposal in terms of moving the render function

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.

into projects directly, instead of importing it from Pylons. This makes

Cheers,
Ben

If you're using Genshi/Mako in the standard 'Pylons way' of using 'c' for variables, the included render_ functions are provided by Pylons. No need to write them yourself. MakoRenderer is 'ad hoc' as much as render_mako. Can you clarify what makes one of them less ad hoc purely because its a class rather than a function?

smime.p7s
Description: S/MIME cryptographic signature