blog.log2e.com

Version 1.8 of the Zend Framework introduced a whole new concept of bootstrapping an application. The core functionality is contained in the Zend_Application component which supports a strictly object-oriented approach to bootstrapping. Although the new concept is fairly straightforward, it does take a little time to get used to it if you are used to the bootstrapping process in earlier versions of ZF.

One of the many interesting features of Zend_Application is the ability to push resources into resource plugin classes which can be utilized simply via configuration. In this tutorial we will be looking at creating a custom resource plugin. The plugin is quite simple, it creates a “value object” with the name, author and version of the application, and stores it in the Zend registry.

Standard Resource Plugins

Version 1.8 ships with a set of standard resource plugins that can be found in the library/Zend/Application/Resource folder:

It’s worthwhile to take a look at the source code of these classes. The use of the available resource plugins is described in the Reference Guide. The idea behind the resource plugins is to encapsulate common bootstrapping tasks like setting up a default database adapter, configuring the view, etc.

What makes the resource plugins etremely useful is the fact that the Zend Framework automatically initializes the plugins according to the options set in the application’s configuration file. You only have to make sure that you provide the proper combination of keys in the configuration file. The first key has to be “resources”, the second key has to be the name of the resource plugin, and any further keys should reflect the names of the required options. This way you can even add new resources without needing to touch the bootstrap class itself. (We will look at a sample configuration file shortly.)

The AppInfo Resource Plugin

The need to display the application name, version number or author name in different places of the UI (including the browser title) is quite common. There are several ways of doing this in ZF, but for the purpose of this tutorial we will be using a resource plugin which makes it easy to re-use this functionality between applications. Our sample Appinfo resource plugin works very similar to the Locale and Translate plugins. It collects information from the configuration file, instantiates an object and stores it in the Zend registry so that the information later can be retrieved from anywhere in the application.

Let’s take a look at the folder structure and the configuration file first:

Please note the different upper and lower case writing (Appinfo vs. AppInfo) which is due to ZF naming conventions.

In order to make this all work we need to provide some settings in the configuration file. Here’s an excerpt from the application.ini inside the application/configs folder (the project setup follows the default folder structure as it is created by Zend_Tool_Project).

As already criticized by Rob Allen, we have to use the key “pluginpaths” to define the directory where the plugin is stored, but use the key “resources” to configure it! (Please refer to the online documentation for more information on these two keys.) I also added the namespace “MyApp” to the Zend autoloader for all classes below the MyApp folder.

The AppInfo Helper Class

The class MyApp_AppInfo in the library/MyApp folder is a helper class which simply holds the information we want to make available via the Zend registry.

The Plugin Class

The actual resource plugin class is MyApp_Resource_Appinfo, and like any other resource plugin class, it extends Zend_Application_Resource_ResourceAbstract. Here’s the complete code:

When the resource plugin is initialized during bootstrapping, a new MyApp_AppInfo object is created if it doesn’t exist. This object gets populated with the data from the configuration file. (The inherited method getOptions() provides an array with the options that were defined in the application.ini file.) Finally, the object is stored in the Zend registry. All this is done automatically, we do not need to do anything “manually” in the bootstrap class or anywhere else.

Usage

Since the MyApp_AppInfo instance is stored in the Zend registry, we can retrieve the information from there. For example, in a controller we can assign the author name to a view variable like this:

Or if we wanted to display the application’s name inside the title tag of our web pages we could utilize the resource from within another resource plugin class. In this case a custom view resource plugin is the most appropriate place to do this:

The important thing here is to enforce the initialization of the AppInfo resource:

$this->getBootstrap()->bootstrap('appinfo');

Finally, there is a possible pitfall that you should be aware of. Even if your plugins do not read any options from the configuration file, you still have to provide the key in the configuration file, otherwise the plugins won’t get initialized. For example:

If you want to learn more on resource plugins, I recommend to take a look at the source code of the standard plugins that ship with the Zend framework. I’m sure you will come up with your own ideas quickly.

Tags: PHP, Zend

This entry was posted on Monday, June 1st, 2009 at 3:05 pm and is filed under PHP, Zend Framework. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.