Kevin Dangoor wrote:
2. The spec is changed immediately to allow arbitrary keywords, and
plugins are expected to ignore keywords they don't understand. Later
keywords can be added to control aspects, hopefully with reasonable
compatibility. For instance, it is not horrible if a template plugin
ignores the search path (confusing, maybe).
I can get behind this one. I'd be interested in hearing Christian's
perspective. (There are also 3 other people, all on this list I
believe, that have written plugins.)
3. The plugin instances grow a new method like "set_search_path()".
Consumers should check for the existance of this method, and call it if
necessary.
It seems like the more pythonic thing to do is just say
plugin.search_path = [...]. If a given plugin needs behavior to go
with that, it can implement a property. A framework using the plugins
can set the search_path and the plugin can decide whether or not to
use it.
This is my favorite choice. It's completely compatible and pretty
reasonable. #2 is just a little more concise.
Setting the attribute is pretty much the same as allowing arbitrary
keyword arguments. Except it's not a usual way of handling this in
Python. Possibly ignoring keyword arguments is more common than
ignoring attributes someone else sets. Also, if the plugin doesn't
implement a search path, should it raise an AttributeError? But it
can't do that for future things it doesn't yet know that it doesn't
implement. If it can, then frameworks need to know that they should
catch that error.
The advantage of checking for the existance of a method is that you can
tell if the plugin implements a search path. If it is optional, it
would be nice if the framework could warn you if you are using something
that doesn't implement it. I think that's particularly true in this
case, because bugs where stuff just doesn't have any effect can be
particularly frustrating.
Plugins could also have a "features" dictionary with some list (or
dictionary) of features they implement.
Another thing that just occurred to me -- some templates quote
everything by default, some don't (Cheetah and Kid are opposites, for
example). quoted and literal methods would be nice. Nothing urgent,
but it just occurred to me now...
literal in Cheetah would do nothing, would be XML() in Kid; quoted would
do nothing in Kid and HTML/XML quoting in Cheetah -- that would make it
easier to generate markup and messages that would work in multiple
templates, maybe solving most of the incompatibilities between widgets
and non-Kid languages. Or perhaps better, we could define specific
types that indicate one or the other mode (literal or quoted) and the
template plugin would figure it out; things wouldn't magically be
compatible across templating languages, but you wouldn't have to know
the plugin would were working with ahead of time if you wanted to make
an agnostic library. In that case, for instance, Kid would be updated
or monkeypatched in the plugin so that in addition to ElementTree nodes
it would also recognize these special types as not requiring quoting.
And Cheetah would probably be run with an appropriate filter. But
that's another aside, maybe more appropriate if common operations are
implemented in some shared library. Or it could use magic methods.
BTW, I'm copying Ben Bangert, as he also added template plugin support
to Pylons the other day.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
