Plugin Architecture: Hooks and Callbacks

[eluser]Xeoncross[/eluser]
That is a perfect sum-up fatbear. 5 stars!

In a more recent conversation Colin and I talked about a way to implement something like this. Right now most systems enable the call from the code:

Code:

//Add a plugin call to myfunction()
$plugin->add('hook_name', 'myfunction');

Then when the system gets to "hook_name" and runs it - it calls "myfunction" and passes it some data to modify or something. That is how wordpress and others give 3 partys the ability to change/add to the existing code. They auto-load all plugins on startup(like read_dir) and when each plugin is loaded it runs the above code to add itself to the plugin registry so that it gets called.

I think that rather than embedding the hook/pluginname into the code of each plugin (and then auto-loading all plugins on startup) we should use a config file for a CI version (just like the way "hooks" are used in CI).

This not only makes it easier to remove calls to certain plugins - but what if someone else comes along and wants to use another plugins call within a plugin.

Just change the config file.

So I was thinking about extending the "hooks" class to allow other plugins (from now on called "hooks") to be loaded and called when needed. The current hooks class only has 8 places to call from and locks the developer out of creating more hook-on places.

Code:

$hook['myhook'][] = array(
                    'function' => 'render_layout',
                    'filename' => 'render_layout.php',
                    'filepath' => 'hooks'
                    //'class'    => 'layout',
                    //'params'   => array('red', 'yellow', 'blue')
);

I am going to start extending the core hooks class as I think that is the best way to leech on to the existing "hooks" stuff without changing the way others are used to using CI.

Note: All this was a call for help