Contemplation of Plugin Models

Posted by santosj on August 26, 2008

Adapter Class Pattern

The advantages lies in knowing the inner architecture of the classes. I can extend the system with minimal documentation, but an outsider would require more details.

I can’t give out any packages since I very much find anything I use extremely useful. The entire point, is that with enough time, everything makes sense. If I don’t have much time, I want a quick as possible fix that does what I need. If I did not code the package, then I have no idea where to begin (even after reading the documentation, if it is detailed enough).

My first prototype was this, a class would extend a base abstract class which would offer methods for allowing other classes to plug into that class. The child class would then call those “plugins” when needed. It would work fine, but I felt that the finished design would still be flawed, so I never finished it.

“WordPress” Model

I use WordPress, since I work most with it, but I found it within other web applications. I laughed at what I thought was a poor design when I first looked at the code. I think that after using it for a while, that its ease and speed to get plugins functional really appeals to me.

It is a wonderful implementation to allow for hooking into systems by such a simple method. A simple method that does not require knowing which class or function will use it. Only knowing the hook name and the parameters that will be passed (also, which function to use).

function myAction()
{
    // Do stuff
}

add_action('some_hook', 'myAction');

WordPress combines all of the hooks into a single global variable. The code is something, but it works by using call_user_func() and storing the second parameter in add_action or add_filter functions. It is placed in an array with the first parameter name. That way, any number of functions or methods can be run without overwriting any others. There are other mechanisms, but the code exists, so enjoy.

Pluggable Plugin Model

The idea has been wandering around, but I feel the best way to solve my issue is to code it and see what happens. Some of the prototype is in Quantum Game Library in some form of TDD.

I think where I lose faith is with the Singleton model. However, I’m debating whether it wouldn’t be the best way to do it. How else would you pull in the plugin model without using a function or Global to hold the class?

Adding a Hook Type

The hook type controls what happens when different methods are called. This is to create a uniform structure for all hook types and still allow for custom control for those special cases where database queries are needed.

In most cases a generic class can be used, in that case then I think the base module structure should be like so. The first example is for custom hook objects and the second is for using the generic hook object.

// Example 1
MyPlugin::getInstance()->register('mycustomhook', new MyPlugin_Module_Hook);

// Example 2
MyPlugin::getInstance()->register('myhook');

Adding a Hook to the Hook Type

I really think it would make sense to use __call() magic method for calling the objects. This would abstract the class structure to allow for changes to not affect the code that calls it. The __call() would use the first parameter in the register method.

function myAction()
{

}

MyPlugin::getInstance()->myhook('some_hook')->add('myAction');

Chaining

Adding multiple modules:

MyPlugin::getInstance()->register('action')
                                ->register('filter')
                                ->register('options', new Custom_Module_Options);

Adding multiple hooks:

MyPlugin::getInstance()->action('some_hook')->add('myAction')->priority(10)
                                ->action('some_hook')->add('myAction')->priority(5);

Calling a hook:

MyPlugin::getInstance()->action('some_hook')->call();

Possibly Related Posts:


Uncategorized

Comments are closed.