Re: Proposal: write plugins as classes

On 04/01/05 05:19, will guaraldi wrote:
> 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
> 

re 3.
I was thinking about servers that cache loaded modules (e.g.
mod_python). This is the reason I started storing stuff in the data dict
instead of module level vars. Constants are not a problem, just talking
about state and temp vars.

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

Ups. Thanks for not just saying RTFM ;-)

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

I haven't bumped into this problem myself yet. Just thought about it
when once again storing something in the data dict.
I was thinking about possible name collision. If I store something in
the data dict as data['funky_member'], and then, half a year later,
someone writes another funky plugin and also thinks funky_member is good
name to store his stuff. That could lead to hard to find bugs and funny
behaviour.

That said, the problem can offcourse happen anyway as all plugins can,
and are ment to, contribute to the data dict. It would minimize the risk
though, as temporary vars and state vars are more likely to have
identical names than template vars.

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

To be honest I also couldn't think of anything to put in the PluginBase
class atm. But it would give us the chance to do so in the future
without breaking existing plugins.

cheers
Steven


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