debuggable

Important: This is no official way to use plugins and also no complete step by step tutorial for the things I do with plugins. This post is aimed at advanced CakePHP users trying to get more out of plugins.

Working with plugins in CakePHP is tons of fun and I had good success with it so far. However, there were two things I struggled with: Inter-Plugin Communication as well as filter callbacks.

I want to begin to talk about filter callbacks. In SpliceIt!, I want plugins to be independent pieces of useful functionality that are very simple to integrate (just drop the folder into app/plugins). Out of the box, CakePHP plugins seem to be capeable of providing this structure, but at one point I hit a difficulty:

Plugin Callbacks / Hooks

Imagine you want to have a Statistics plugin, that logs every hit on your website and provides a nice interface for viewing those statistics. Doing the interface is easy in CakePHP, but for logging each hit, your plugin would need to be called every time an action is requested. Now, you can do this by using $this->requestAction(..) in your AppController's beforeFilter, but if you start to have lots of plugins that can be around 10-20 dispatching actions for every hit and performance might suffer. Another drawback to this strategy is, that you will always have to change code in your AppController to integrate a new plugin, which doesn't seem like a very RAD approach to me.

So in order to streamline such plugin callbacks, I created a function inside SpliceIt!, that allows plugins to hook into any AppController event, such as beforeFilter, afterFilter, beforeRender, etc. in order to make their own changes to the controller. So a Themes plugin can easily change the Controller::view and a Statistics plugin can make calls to a Model.

Here is the function I use for triggering those event's, if you want to see the complete implementation, I suggest you to checkout the splice_it.php from the current trunk of SpliceIt!.

So now the only modification that needs to be made to the AppController, is to call this function for each filter. Here is an example for the beforeFilter:

So if you now want to make a Themes plugin you can simply create a file called hooks.php inside app/plugins/themes/ and make it look like this:

I currently use those hooks for UrlRewrite (via $from_url in routes.php), AppController::beforeFilter(), AppController::__construct() and some other important points in my application. However, you can also make plugins trigger their own event's, like blogPostBeforeCreate and such.

Anyway, you remember how I told you, that one could avoid using requestAction for plugin communication? Here is what my current approach for SpliceIt! looks like:

Inter-Plugin communication

Generally spoken Controller::requestAction() isn't a bad way to exchange data between controllers. It's a clean interface and you don't have to plan in advance what data should be exchangeable and what data should not. However, there are a couple problems with it. The first and most obvious problem is, that every time you use requestAction(), the entire dispatching process is executed again, which is almost like having a second hit on your site (well not quite as bad, but still). In a normal application this isn't that big of a problem, since there won't be more then 1-3 requestAction's executed per page which doesn't hurt performance that bad. But if you have a system of plugins where you can't share Models,Views and Components as easily as you can in a regular app, you might need up to 20++ requestAction's per page to make things work. And at this point it really get's inefficiant. Because creating instances of Controllers, Models, and Components over and over again takes a lot of cpu cycles.

Another drawback to requestAction() is, that when a Controller/Action or View is missing, CakePHP will render an error page and execute exit; leaving no way of error handling to you. You could create your own AppError handler and change this behavior, but I didn't like this approach that much.

So what I figured was, that the best way of exchanging data between plugins, would be to have special ApiControllers, that do nothing but manage the exchange of data between plugins. They would be normal controllers hidden from the public and only one instance of them would be created when needed, and then shared amongst all other (plugin) controllers. Those ApiControllers normally wouldn't have any Views coupled to them, and therefor only be MVC pieces in your app.

So far I have a working implementation of this ApiController pattern of mine in SpliceIt! and it works like a charm. Performance made a significant jump (3-4x faster) compared to requestAction, and the code looks a lot prettier. I'll try to share the most significant parts of it now, but you should definitly checkout the SpliceIt! trunk for getting a deeper inside into the entire process.

First of all, I'll show you the SpliceItApiController, that I use as the base class for all my ApiController's. Since the ApiController's are sort-of Singletons I added a getInstance() function to them:

You don't have to know about the SpliceItAppController for now, just imagine it to be your normal AppController.

Now here is how one of this ApiController's could look like:

Now when you want to add a User using the UsersApi in one of your controllers, you can simply do it like this:

Now the thing that is still missing, is the way how $this->UsersApi actually get's loaded. I use my own AppController called SpliceItAppController and it contains a function like this:

And here is how SpliceIt::getApiInstance() looks like:

Now you see that all of this isn't that easy to do, and if your project isn't aimed at becoming all that big and using tons of plugins you can easily go with requestAction(). But if you are trying to make a heavily modularized application like I do with SpliceIt! you might find yourself in need of using similiar strategies as the ones presented above. If you have any questions concerning the code above, or SpliceIt! in general, feel free to ask I'll try to answer as good as possible ; ).

--Felix Geisendörfer aka the_undefined