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.

Introducing the Gateway Controller

Setting up a Zend AMF server inside a Zend controller is pretty easy:

Since we do not want to output any visible content we disable the view renderer (otherwise the action controller will look for a view script in a subdirectory named after the controller). The endpoint URI of our AMF server gateway is now something like http://www.mydomain.com/gateway/, and doesn’t interfere with our other controllers. By calling the addDirectory() method we tell the server where to look for the services. We only need to provide a base directory here. If we set up our remote objects in Flex with full namespaces the AMF server is able to resolve the dot syntax into the appropriate path.

For example, the dot syntax in the source attribute of this remote object

<mx:RemoteObject id="articlesRO" showBusyCursor="true" source="com.xeladon.cms.ArticlesService" destination="zend"/>

will be transformed into the path com/xeladon/cms/ArticlesService. Please note that in this setup there is no need for explicitly propagating each service class to the server with the setClass() method. For more information on the different approaches (addDirectory() vs. setClass()) please refer to Wade Arnold’s blog post on Lazy Loading Classes.

Organizing Value Objects with Namespaces

Now let’s take this one step further. As a long-time AMFPHP user, I have gotten in the habit of organizing my value objects with namespaces. I usually put my VOs in a folder below the service classes:

We can still do this with Zend but we have to make sure that Zend Loader is able to find the VO classes. I suggest adding the path to the include path in the index.php file:

Adding More Functionality

Based on the above setup, we can easily add more functionaliy to the bootstrap file without worrying about the AMF server gateway. We would probably want to make use of Zend_Config for configuring the application, and Zend_Db for managing database interactions. By adding a few more lines of code to the bootstrap file, these functions become automatically available to the AMF service classes.

Let’s assume we set up a database adapter in the bootstrap file. This allows us to write very clean code inside the service classes. The following code is just an example (where ArticleVO is a typical value object, and Articles is supposed to be a Zend model class that extends Zend_Db_Table):

Summary

What do we gain with all this?

1. We keep things organized and can rely on the same structures (packages, folders, namespaces) in both ActionScript and PHP.
2. We can use other powerful features of the Zend framework for the application’s server-side logic.
3. We have the flexibility of adding Flex/Flash and HTML interfaces to the same core application whenever and whereever needed.

I would like to introduce a Zend AMF server setup that makes use of some of Zend’s best practices like configuration files, database adapters and models. If you are a Flash/Flex developer coming from an AMFPHP background and have never worked with the Zend framework before, you may easily feel overwhelmed by the framework’s complexity. This article is not meant to present a thourough overview of all Zend features you could possibly utilize in your Flex/Flash development work, but it might motivate you to dive deeper into the framework’s features.

The Folder Structure

First of all, even if I only need the AMF server from the Zend framework I set up my server directories like I would do with any other Zend/PHP application. If you already have some experience with the Zend framework this folder structure probably looks familiar to you:

This is a rudimentary folder structure, of course, because a typical Zend application with an HTML frontend has additional folders for controllers, views, layouts, forms, plugins, helpers, etc. But the basic setup is the same: We have an application and a library folder that are outside the web server’s root directory (public). The Zend framework packages are inside the library folder, and below the application folder there are a config and a models folder. For the special purpose of the AMF gateway, I added a services folder which is supposed to contain all service class files.

The Database and the Configuration File

Let’s assume we are working on an application that needs to manage user accounts. A very basic table would look like this:

The database credentials are stored in an INI file (app.ini). In this example there are configuration data for both a production system and a development system. Because the development system configuration data are very similar to those for production, the development section inherits from the production section:

This configuration file also allows you to easily change the database adapter (if needed).

The Bootstrap File

Let’s take a look at the bootstrap file (index.php):

This bootstrap file is very similar to the standard bootstrap files you find in other tutorials or in the Zend Reference Guide. It adds some include paths, initializes the Zend autoload feature for classes, and sets up the AMF server.

The Service Classes

Utilizing the Zend_Config and Zend_Db packages, we set up the database connection in a base service class that the actual service classes inherit from. In line 7 in the listing below we provide a default database adapter for all subsequent instances of Zend_Db_Table objects in our application (for more information, please refer to the Zend_Db chapter in the Reference Guide). This way we keep the logic of creating a database connection in one central place.

The only real service class in our example is UsersService which extends BaseService and invokes the parent class’s constructor by calling parent::__construct();. For the sake of simplicity it contains only one method (getUsers()):

You may wonder what the Users class does (line 12 in the above code listing). Here’s the answer: It’s a model class.

The Model Class

Models are another important concept of the Zend framework. Although the classical MVC pattern doesn’t apply in the context of the Zend AMF server, I stick to this concept here because it may come in handy sometimes. Imagine an application that is supposed to support both a Flash and an HTML interface. By following the framework’s MVC guidelines, we are able to build an application engine that uses the same model classes for both the AMF server gateway and the MVC-based HTML frontend.

The class Users is located in the models folder. It extends Zend_Db_Table and holds the name of the corresponding database table:

Remember that we provided an application-wide database adapter for all Zend_Db_Table objects (see line 7 in the BaseService class). By creating an instance of Users (which inherits all methods from Zend_Db_Table) we are able to use fetchAll() to retrieve all rows from the table users.

The Value Object Class

The class User (see line 17 in the UsersService code listing) is a helper class that allows us to send an array of typed objects to the Flash player. This is especially useful in Flex-based applications where you want to use value objects for data-binding, for example. By the way, the class User doesn’t look any different than a VO class in an AMFPHP context.

By calling $server->setClassMap('UserVO','User'); inside the bootstrap file, the User objects are mapped to UserVO.

I skip the Flex/Flash part here because this topic is well covered in other tutorials. But I hope you caught a glimpse of how you can leverage the power of other components inside the Zend framework – even if you are only interested in the Zend AMF server. There are more scenarios where the Zend framework may come in handy for a Flash/Flex developer (for example, think of generating PDF files on the fly by using Zend_Pdf).