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]>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
