Sir Robert Burbridge <[email protected]> writes: > On 04/08/2010 05:46 AM, Dan Horne wrote: >> >> I have a question regarding the best method for implementing application >> plugins - i.e. if there is an idiomatic way to do this in Moose. Here's a >> high level description of what I'm trying to achieve: >> >> 1. When the application starts, it finds all modules in a "plugins" >> directory. >> 2. We loop through each module in turn: >> 1. We call a register method, which registers the plugin (this method >> returns the plugin name). This becomes the key in the "plugins" hash >> 2. We then call a the plugin "functionality" method (I don't have a >> good name off the top of my head), which returns an anonymous >> sub containing the plugin functionality, (or perhaps a callback >> method name) >> 3. Now, whenever the plugin is called by name, the supplied >> "functionality"method is invoked
[...] > http://search.cpan.org/~groditi/MooseX-Object-Pluggable-0.0011/lib/MooseX/Object/Pluggable.pm For what it is worth, when I had a similar set of needs, and a similar idea of how plugins would work to Dan, I tried MooseX::Object::Pluggable. It didn't do what I wanted especially well, for several reasons: It failed on point 1, since it didn't provide good mechanisms to enumerate and load all plugins, only to load named plugins. I ended up using Module::Find or so to locate all the bits of code. It failed on point 2, since it composed the plugins to my current instance, rather than letting me register them. This worked for some features, but poorly for others. For example, I wanted to use plugins to register data sources, and to format outputs. For the later it was fine: I could use the plugin to extend a "format" method, and all was good. For the registration of data sources, however, I wanted to provide a central registry of "protocols", and allow one plugin to provide many protocols; the specific use-case was allowing fetching via HTTP and HTTPS from a single plugin. Ideally, in fact, I would like to have had a factory method that allowed me to match plugin instances to desired services, and to create an instance of the best matching plugin, in an abstract way — without extending any object at all. So, while the design of the module you suggest is good, it isn't actually all that useful for a range of uses of plugins. Not that I wrote any useful code to fix those problems, as that project is languishing in idleness at the moment. Daniel -- ✣ Daniel Pittman ✉ [email protected] ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons
