Re: Re: Request For Comment: Web Application Plugin Manager

[andreychek]

I spent some time wondering why the driver config files weren't simply set up as modules subclassing the more general categories of interface and protocol layer

Well, if I understand what you mean here, I think the answer is that drivers in OpenPlugin typically *are* subclasses of more generic Plugin modules, and Class::Factory helps me do that.

Class::Factory is about being able to load/use classes dynamicly. So even with having the drivers as subclasses, we still don't necessarily want to load every plugin or driver at once. There are cases though when we would want to load a plugin or driver at load time, and Class::Factory accommodates us there too.

Each plugin uses Class::Factory as a base class (actually, more technically, each Plugin uses OpenPlugin::Plugin as a base class, and then OpenPlugin::Plugin uses Class::Factory as it's own base class). Class::Factory then provides a consistant method for loading each plugin via it's new() constructor. So, new() is part of Class::Factory, but inside that constructor is a call to init(). A plugin or driver may implement init() if it wants to do any custom initialization stuff.

I'll have to take a look at POE to see how they're working things.

Thanks for your thoughts,
-Eric


--
Lucy: "What happens if you practice the piano for 20 years and then end up not being rich and famous?"
Schroeder: "The joy is in the playing."