Kevin Dangoor wrote:
I think the plugin standard that we setup should stay as basic as
possible. IMHO, the plugin should busy itself *only* with rendering
output based on an already supplied path to a template and a dictionary
of parameters. That's it. Anyone using the plugins can choose to
implement search path behavior in their app/framework/whatever and then
use the plugin to do the actual rendering.
It's either that, or we create a small project with a base class to
support these plugins. Since not all template packages themselves
support search paths, it would definitely be a shame for each plugin
to have to implement this behavior.
It could also be brought into plugins via svn:externals, so that it
isn't just a shell of a project. Many packages do support search paths,
so it's not entirely necessary -- though few (any?) support search paths
using pkg_resources for some of those paths.
I actually think that it may make sense to create a small "template
plugins" project to have a base class and maintain the interface. That
way, it's easier to improve on the interface over time. It would allow
us to use setuptools requirements to ensure that the plugins that are
loaded support the interface that's used by the framework...
If there's common code that can be applied for locating a template,
then I'm okay with that. Otherwise, if search_path is something that
only certain engines will support, the "options" dict is a better
place for it. Besides, the user may want a different search path for
different engines they're using anyhow.
I would like the interface to be suggestive of the features the plugins
should implement. If people want to make reusable applications at all,
this should be considered a bare minimum feature for that.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
