In Zend Framework 2.0, we're refactoring in a number of areas in order to increase the consistency of the framework. One area we identified early is how plugins are loaded. The word "plugins" in Zend Framework applies to a number of items: Helpers, Application resources, Filters and validators and Adapters.

In practically every case, we use a "short name" to name the plugin, in order to allow loading it dynamically. This allows more concise code, as well as the ability to configure the code in order to allow specifying alternate implementations.

The current versions of the framework use a "PluginLoader" class that handles the resolving and loading of the plugins as they're called. With this new PluginBroker, the process is optimized and split out into some namespaces for ease of use. He gets into more detail about the class resolution, instantiation, registration and touches briefly on the PluginSpecBroker, a special-case handler that's a concrete example of the LazyLoadingBroker.

Associated websites often share user information, so a visitor only has to register once and can use that username and password for all sites. A good example for this is Google. [...] There are many single sign-on applications and protocols. Most of these are fairly complex. [...] I've written a simple single sign-on solution (400 lines of code), which works by linking sessions. This solutions works for normal websites as well as AJAX sites.

He compares the flow on a non-single sign-on site (lots of fetching between the client/server) and the first/following visits with his tool in place. You can download the source here (as well as the Ajax broker).

Zend_Controller_Plugin is not covered yet in the documentation but it is a powerful way of extending a controller. Briefly, Zend_Controller_Plugin is used for extending controller functionality by attaching listeners to events, which are fired (or trigged) by the controller classes.

He talks about the plugin interface, how it hooks into the controller and defines the relationship with some pseudo-code (showing implements versus extends). There's talk of the Zend_Controller_Plugin_Broker class and the Zend_Controller_Front. He looks in detail at this last class, showing how it helps to handle incoming requests for the plugin functionality and veen includes working code you demonstrate how.