On 1/18/06, christian <[EMAIL PROTECTED]> 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. 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. Kevin
