TG2 follows the Pylons config format 100% right now. Which is fine with me now that i grok some of the thinking behind it. but I have to agree that the template stuff is convoluted and confusing. At least I'm confused, and therefore apparently TG2 doesn't do things right, and I still don't quite know how to make things right.
We tried to set it up in the DecoratedController to lazily prepare only the engines that get used, and to set a default so that if no engine is specified we use that default. To do that we need to be able to find the default engine at controller initialization time, which is harder than it looks. :( I don't so much mind preparing engines that aren't used yet, if people can easily control what's in their app. But it seemed nice to me to lazily prepare engines based on data from some configuration object (or in the current case from the list). That way we can set defaults for all the major template engines, and they will all just work and only be loaded if they are used. But that's just a nice-to-do the key thing for me is to make it easy for users to say they want genshi, or mako or whatever templates to be used by default if no template engine is specified in the @expose() decorator. On Dec 12, 2007 11:50 PM, Mike Orr <[EMAIL PROTECTED]> wrote: > > On Dec 12, 2007 4:47 PM, Mark Ramm <[EMAIL PROTECTED]> wrote: > > > > What I want, and what seems to make the most sense to me is for there > > to be a default engine which is used when no engine is chosen, and for > > users to have to declare an engine the want to be the default. I > > expect most users in a TG2 world filled with html, rss, json, xml, > > amf3, and all kinds of other protocols to live in a multi-engine > > setup. So I want to be able to make it easy to configure all your > > engines, and easy to choose which one is the default > > > > I the simple case, I don't want users to have to do the list dance to > > declare a default engine And I want it to be done in a standard way > > across TG2 and pylons so we don't have to document it as a difference > > -- unless there is some compelling reason to make it different. > > > > So, my proposal at the moment is to add a defaul_engine to be setup in > > environment.py. The list can still be there, and can still function > > the same way, it's just that rather than get the default from the > > first item in the list, we'll get it from default_engine. > > This is already there, if I understand you right. The default > environment.py contains: > > config.init_app(global_conf, app_conf, package='myblog', > template_engine='mako', paths=paths) > > To make Genshi the default, replace 'mako' with 'genshi'. > > What's convoluted is the way to add additional engines and set > options. It's an interaction between config.add_template_engine, > 'buffet.template_engines', 'buffet.template_options', and > pylons.wsgiapp.PylonsApp (instantiated in middleware.py). > > environment.py says: > > # Customize templating options via this variable > tmpl_options = config['buffet.template_options'] > > This variable is docstringed as: > > Full dict of template options that any TG compatible plugin should > be able to parse. Comes with basic config needed for Myghty, Kid, > and Mako. (In pylons.configuration) > > Of course, this really tells the user what options are available. The > first sentence seems to imply each option should be prefixed with > "enginename.". > > 'buffet.template_engines' is docstringed as: > > List of template engines to configure. The first one in the list will > be configured as the default template engine. Each item in the list is > a dict indicating how to configure the template engine with keys: > ``engine``, ``template_root``, ``template_options``, and ``alias`` > (in pylons.configuration) > > All config.add_template_engine does is append a record to > 'buffet.template_engines', using 'buffet.template_options' as the > options. Note that the latter contains all options for all engines, > and the user is given no opportunity to customize it before the > default engine is set. (Because config.init_app both initializes > 'buffet.template_engines' and configures the default engine.) > > Later when pylons.wsgiapp.PylonsApp.__init__() is called, it > initializes a Buffet with 'buffet.template_engines'[0], then loops > through the other elements, calling self.buffet.prepare on each. > > What a bunch of convolution crap. > > Buffet2 will not keep track of engine names and renderers. Pylons > will have to do that, and invoke the appropriate engine (renderer) > directly when needed. > > My difficulty in cleaning this up is I don't know what all the options > are for each engine, how sane the Pylons defaults are, how the options > will change in Buffet2's renderers, and which options the users will > likely want to set for each engine. Since I don't do the Genshi > multi-output-format thing, I don't know what power Genshi users would > do. Buffet2 also wants to make a hard distinction between engine > options (set here) and rendering options (set in the render() call). > I would like to get the default options organized better, but on the > other hand it ain't broke even though it's ugly. > > So, what shall we do? I think the two variables and three method > calls can be streamlined to one API. The list of engines can go; what > matters is a dict of named engines and a choice of one of them as the > default. > > PylonsApp is the workhorse; everything else is just preparing for it. > Yet PylonsApp is in middleware,py and we want the template > configuration in environment.py. > > The most straightforward way is to strictly separate init_app, > add_template_engine, and > set_default_template_engine(engine_name_already_added). The > 'template_engine' argument would be eliminated, or a shortcut for > calling the latter two methods. Re-adding an engine would replace its > previous configuration, to handle the case of setting options on the > preconfigured default engine. Thus, 'buffet.template_engines' would > behave as a dict even if it remains a nominal list, and > 'buffet.default_template_engine' (string) would be added. That's *IF* > all this really needs to go into the config rather than into some > instance attribute. > > I'm not sure what to to about 'buffet.template_options'; I'd rather > see a dict keyed by engine than "enginename." prefixes. "enginename." > prefixes only make sense if we're reading template options from the > config file, and there's currently no infrastructure for this. Nor am > I sure that there are sufficient template-specific deployment options > to justify this. I think our trend is to encourage greater use of > environment.py anyway. > > The big question is how far we're willing to depart from backward > compatibility. If the new API uses non-overlapping config keys, it > can convert the old format to the new format behind the scenes. > > As for TG2, does it use environment.py and production.ini and "paster > serve" at all? Are app.cfg and prod.cfg additional files beyond this? > Isn't three config files a bit much? Could prod.cfg be merged into > production.ini and app.cfg into environment.py? If it doesn't use > environment,py, I don't see how we can have a common template > configuration API between TG and Pylons. > > -- > > Mike Orr <[EMAIL PROTECTED]> > > > > -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
