Plugin framework - Overcomplicating things?

[hajducko at gmail.com]

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>
> wrote:
>
>
>
> > 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
> plugins.
> 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
> handlers[message]()
>
>
>
>
>
> > 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,
>
> André
>
>

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.

--
sh