Re: Proposal: write plugins as classes

On Fri, 1 Apr 2005, Steven Armstrong wrote:

> This is just an idea. I'ld like to here what you guys think of it.
>
>
> Motivation
> ----------
>
> There may be plugins that do similar things or use similar code.
> There's currently no way to extend existing plugins (apart from hacking
> them).
> There's currently no defined procedure to store temporary variables or
> rember state among callbacks. Doing that in module level variables can
> be problematic for environments other than CGI. Storing that in the data
> dict (as I currently do in some plugins) can also be problematic. What
> if some other plugin uses the same name to store something there?

That's actually not true.  If you look at some of the contributed plugins 
we have, there are two methods for storing data between callbacks:

   1. store data in the data dict (this is what it's for)
   2. create an instance of the class and store that in the data dict.
      pycategories and friends work this way.
   3. store stuff on the module level associated with a specific request

The first and second are "well established" mechanisms and they were 
documented in several places on the wiki and on my blog.

I'm not sure what problems arise from storing data in the data dict.  Can 
you elaborate more on that?


> Proposal
> --------
>
> Write a PluginBase class which offers common functionality all/most
> plugins would benefit from.
>
> A plugin could than look something like:
>
> funky.py ------------------------------
>
> from Pyblosxom.plugins import PluginBase
>
> class FunkyPlugin(PluginBase):
>
>  def __init__(self):
>    super(FunkyPlugin, self).__init__()
>    self.beFunky = False
>
>  def cb_start(self, args):
>    """Do some funky initialization"""
>
>  def cb_pathinfo(self, args):
>    path_info = args['request'].getHttp()['PATH_INFO']
>    if path_info.endswith("funky"):
>       self.beFunky = True
>
>  def cb_story(self, args)
>    entry = args['entry']
>    if self.beFunky:
>       entry['funky_message'] = "funky :-)"
>    else:
>       entry['funky_message'] = "Not funky today :-("
>
>  def cb_end(self, args):
>    """Do some funky cleanup"""
>
>
> class Plugin(FunkyPlugin):
>  pass
>
> ---------------------------------------
>
> The plugin loading mechanism would then load the plugin, create an
> instance of the Plugin class and call its cb_* methods as it called
> module functions before.
>
> We could write a wrapper class that handles older plugins that are not
> written like this to be backwards compatible or just check if the Plugin
> class exists or not or something like that.
>
> What say you?

Hmmm...  I think there's definitely an opportunity to centralize some of 
the things we're doing in a bunch of plugins into a plugin class base 
class.  Though more specifically, I'm not sure what I would put in there. 
I think that's definitely worth investigating further.  I'm not sure I 
would change the existing plugin system to use the new plumbing--I think 
I'd rather add the new plumbing onto the existing system.

I am curious as to what problems people have encountered when storing 
things in the data dict.

This is all off-the-cuff.  I'll think about this some more.

/will


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30