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.

Folder Structure

First, let’s take a look at the folder structure on the server. I usually organize my server directories like this:

There is an includes folder on the same level as the amfphp installation folder. The includes folder contains other folders, one for each PHP library (in this case ADOdb, PHPMailer and TCPDF). Download the ADOdb library from here and upload the files to the includes/adodb folder.

globals.php

It is recommended that you add globally used variables to AMFPHP’s globals.php file. Since most of your service classes probably need access to the database this file is the best place for configuring your database settings and the path to your external PHP libraries. So let’s add these lines to the globals.php file:

Of course, you have to adjust the database and path settings to your needs. The INCLUDES_PATH constant should hold the absolute path to your includes directory on the server.

Sample Classes

Let’s say you have a MySQL database that holds a table with product data. For the sake of simplicity, we assume that there are only two fields in this table, product_id and product_name.

If you use the Cairngorm framework for your Flex application you are familiar with the concept of Value Objects (VOs). Instead of using XML or simple arrays, VOs allow for sending back and forth typed objects between Flex and AMFPHP. We define a simple ProductVO class and place the ProductVO.php file in AMFPHP’s services folder.

Now we add a service class (ProductsService.php) to the services folder. The ProductsService.php file includes the ProductVO class and the ADOdb library. The constructor establishes the database connection (for the syntax take a look at the ADOdb documentation), and the getProducts() mehod retrieves all products from the database, wraps them into ProductVO objects and sends them back to your Flex application.

In a similar way you can add other PHP libraries to your AMFPHP classes (like the above mentioned PHPMailer and TCPDF libraries). I hope this example helps you to utilize the power of some of the most popular PHP libraries for your Flex applications. If you have suggestions or requests please comment or get in touch with me.