Plugin framework - Overcomplicating things?
hajducko at gmail.com
hajducko at gmail.com
Thu Mar 27 20:25:29 CET 2008
On Mar 27, 4:18 am, André <andre.robe... at gmail.com> wrote:
> On Mar 27, 3:31 am, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
> > En Thu, 27 Mar 2008 01:50:56 -0300, hajdu... at gmail.com
> > <hajdu... at gmail.com> escribió:
> > > All this comes to my question - am I overcomplicating this project? I
> > > can understand the use of something like the trac component system if
> > > I had multiple components and plugins that handled different areas of
> > > my project and different points of interaction, but I don't. I've got
> > > exactly one spot where I want to check all my plugins and hand off the
> > > message to which ever ones are looking for that command.
> > As you said, it looks like you're really overengineering your design then.
> > > So really,
> > > should I even bother with trying to setup some framework for this or
> > > should I just be doing a simple loop over a directory, importing all
> > > the plugins and storing them in a list and then looping over them in
> > > the message handler to see which ones were looking for the command and
> > > letting them do their thing?
> You could set thing up so that there's no need to loop over the
> What you can do is register a plugin (as mentioned to you before by
> Gabriel - see below) and create an entry in a handler dict so that you
> can directly dispatch the message to the appropriate handler without
> having to loop over a list of them. Something like
> > That may be an option.
> > You may want to setup a simple registry mechanism, so the plugin modules
> > look like:
> > ### begin niceplugin.py ###
> > class AVeryNicePlugin(object): # or perhaps using a suitable base class
> > def handle_message(self, message):
> > ...
> > from plugin import PluginRegistry
> > PluginRegistry.register(AVeryNicePlugin)
> > ### end niceplugin.py ###
> > Your application scans a known directory for files ending in "plugin.py"
> > and imports them; the modules register themselves any class (or classes),
> > and at appropiate times the application calls some method(s) of the
> > registered plugins.
> An alternative (which we found simpler with Crunchy) is to not have a
> class-based structure, but working with simple modules and functions.
> All modules are put in the "plugin" directory which are imported at
> the beginning. Each module contain at least two functions:
> 1. register() which create the handlers dict entry so that it point
> out to the appropriate function.
> 2. one or more function that is called based on the message received.
> Hope it helps,
Thanks for the replies. André, you're alternative was exactly what I
was thinking of falling back to, rather than setting up class-based
plugins. Like I said, seems like a whole plugin framework would be
wayyyy too complicated. The only reason I figured I'd loop over the
available plugins was in case two were defined to handle the same
message. I figured something like setting an 'command' attr in the
module and just checking for that. Either way, I think I'll stay away
from trying for a real framework in this case.
More information about the Python-list