Is it possible to load a controller?

[eluser]Rick Jolly[/eluser]
Colin, yes your example is so specific that I'm having a hard time believing there could be more than one implementation for that "blog_build_post" method. But, your plugin stuff could be more useful with something more generic. Maybe take authentication as an example. Switch in/out plugins that all implement an "authenticate" method and expect username and password parameters.

IMO your main benefit is that you don't have to mess with your application code in order to change its functionality. So you succeed in creating some abstraction/modularity with plugins. However, you do have to register your plugins in a config file. So imo, the main drawback is the addition of an extra dependency in the config file. Also, that config dependency is also not very transparent (like hooks or auto-loading).

Your plugins are very similar to Neophyte's KhEvents. Here are what I think are a few differences:
1. You call plugins from your application using a function name. KhEvents trigger an event in the application using some keyword, but it is up to the plugin to register/listen/respond to the event. Your plugins seem to be meant to service your application, while KhEvents put more emphasis on the application servicing the plugin.
2. KhEvents don't use a config file to register plugins. Instead, a directory is scanned for plugins. Plugins are loaded and mapped to the events for which they've been registered. So one less dependency to maintain.
3. You seem use an input and output parameter which is actually quite neat and more flexible. KhEvents just accept an array of data and return a boolean.

[eluser]Colin Williams[/eluser]
Rick , yes, I have had KhEvents brought up when I talk about this system. Thanks for outlining those differences.

Instead, a directory is scanned for plugins. Plugins are loaded and mapped to the events for which they’ve been registered. So one less dependency to maintain.

Taking this approach would certainly shorten the code. And I could modify it so that in the event no config is present, it defaults to this method. I guess I'm setting it up for the event in which a person has plugins installed, just not activated. I see your point though. Although, say you want to distribute your app but not require the user to use all the plugins, while also not making them install each one themselves. It would be easier to seed register_plugins() with an array from a database, so they could enable/disable from a backend, or use the config file.

You seem use an input and output parameter which is actually quite neat and more flexible.

Not so sure what you mean. The invoke() method accepts discrete arguments, supplied to meet the requirements of the hook method. Some hooks need 1 arg, others might require/accept 4 or more. It's up to the plugin to construct their hook implementations accordingly. And hooks implementations don't always need to return anything--it could just update a variable that was passed by reference.

[eluser]Colin Williams[/eluser]

Colin, yes your example is so specific that I’m having a hard time believing there could be more than one implementation for that “blog_build_post” method.

So, the 'comments' plugin tacks on $post->comments_count and $post->comments, but a 'rating' plugin would tack on $post->rating_score, and a 'file attachment' plugin would tack on $post->file_attachments. So there could be many implementations of the "blog_build_post" hook.

[eluser]Xeoncross[/eluser]
You might want to take a look at the plugin/trigger script they built for Chyrp: http://github.com/vito/chyrp/tree/master...rigger.php

I think that a "plugins" dir could be made and then each plugin would have a __construct() or pluginname_setup() function that would tell the trigger class when to call that plugin. That way you could loop through the plugin dir and then (without knowing anything about them) add them to the list of triggers.

[eluser]Colin Williams[/eluser]
For sure, Xeoncross, but from the standpoint of a plugin developer, creating a plugin that's so dependent on the order its hook implementations are called with respect to other plugins is probably best to avoid. I guess it would be fine to at least offer that feature, and maybe hardly document it

[eluser]Xeoncross[/eluser]
[quote author="Colin Williams" date="1217020334"]creating a plugin that's so dependent on the order its hook implementations are called with respect to other plugins is probably best to avoid.[/quote]

Yes, most people will will be fine with running there plugins in whatever order they need - heck, most plugin hooks only have 1 plugin at max (if any)!

BUT for people that need a a plugin to run first - having an extra variable like $priority (default to "5") would be great.

For example:

Code:

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

$priority = 1;
$plugin->add('hook_name', 'me_first', $priority);

It's not like the plugins would build off each other or anything. But maybe you would want to submit the original comment to akismet ($priority = 1) before you run it through your "comment Filter" ($priority = 5) plugin that might remove the spam links that akismet would use to determine it was spam.

[eluser]Eric Cope[/eluser]
Adding fuel to the fire, I recommend using libraries. This enables you to reuse code in multiple controllers and allows you to refactor later to improve performance as you see fit.
This assumes you have long term plans for your code.

[eluser]Xeoncross[/eluser]
[quote author="Eric Cope" date="1217035562"]I recommend using libraries.[/quote]

Absolutely. However, because the CI team never thought to extend the "hooks" class to enabling custom user "hooks/triggers/plugins" we are trying to figure out how to attach functions to certain points in our systems operation that we can't possibly code before-hand.

Plugins are how you deal with code that you will never know or have any power over. It is how you prepare the way for John Doe to turn your submit_comment controller into a ping-o-matic/check-akismet-first/log-update/call-mom/submit_comment controller.

[eluser]Colin Williams[/eluser]
Right, Eric. Libraries, currently, are dormant Classes that must be called directly from the appropriate places. The goal is to not bloat our core processes, but provide an architecture that extends them with very little dependency. As I said earlier, it'd be neat to extend the Library functionality to work in this kind of matter, but I don't think altering core CI behavior is the best idea if the intent is to build a tool for the community.

BUT for people that need a a plugin to run first - having an extra variable like $priority (default to “5") would be great.

I can see the need, for sure, so if I continue down this path (like, if I win the lotto and have nothing better to do ), it's something I'll work in there.

It’s not like the plugins would build off each other or anything.

That's not necessarily true. Nothing keeps a plugin from invoking its own hooks, and implementing them for that matter. This allows plugins to be APIs for other plugins. Yeah, this introduces dependencies, but I think it's still manageable (which, now I guess our plugins need a $requires array property along with $priority, and some reporting mechanism when requirements aren't met. No big deal.)

But maybe you would want to submit the original comment to akismet ($priority = 1) before you run it through your “comment Filter” ($priority = 5) plugin that might remove the spam links that akismet would use to determine it was spam.

Good example. This hints at some of my concerns for this system we're talking about. Without being really creative or introducing new conventions, such plugins can only go so far. Take the comment plugin example. There still needs to be a Comments controller and Comments model to handle posting comments, managing comments, viewing comments, etc. These other components will be invoking their own hooks, but what's the recommendation for a comments plugin implementing these hooks? I mean, you could invoke a 'comment_save' hook from the controller and skip the model altogether, which would be a bad practice. And does a plugin use a model for all database interaction, or does it run it's own queries?

These answers come down to a number of factors, like context and personal preference. And perhaps the flexibility of these plugins would be seen as a feature? It just needs more study and development... I'm just talking to myself at this point, I think....