Using the CLI Tool
Zend_Tool_Framework
Programmer's Reference Guide

Architecture

Registry

Because providers and manifests may come from anywhere in the include_path, a registry is provided to simplify access to the various pieces of the toolchain. This registry is injected into registry-aware components, which may then pull dependencies from them as necessary. Most dependencies registered with the registry will be sub-component-specific repositories.

The interface for the registry consists of the following definition:

  1. interface Zend_Tool_Framework_Registry_Interface
  2. {
  3.     public function setClient(Zend_Tool_Framework_Client_Abstract $client);
  4.     public function getClient();
  5.     public function setLoader(Zend_Tool_Framework_Loader_Abstract $loader);
  6.     public function getLoader();
  7.     public function setActionRepository(
  8.         Zend_Tool_Framework_Action_Repository $actionRepository
  9.     );
  10.     public function getActionRepository();
  11.     public function setProviderRepository(
  12.         Zend_Tool_Framework_Provider_Repository $providerRepository
  13.     );
  14.     public function getProviderRepository();
  15.     public function setManifestRepository(
  16.         Zend_Tool_Framework_Manifest_Repository $manifestRepository
  17.     );
  18.     public function getManifestRepository();
  19.     public function setRequest(Zend_Tool_Framework_Client_Request $request);
  20.     public function getRequest();
  21.     public function setResponse(Zend_Tool_Framework_Client_Response $response);
  22.     public function getResponse();
  23. }

The various objects the registry manages will be discussed in their appropriate sections.

Classes that should be registry-aware should implement Zend_Tool_Framework_Registry_EnabledInterface. This interface merely allows initialization of the registry in the target class.

  1. interface Zend_Tool_Framework_Registry_EnabledInterface
  2. {
  3.     public function setRegistry(
  4.         Zend_Tool_Framework_Registry_Interface $registry
  5.     );
  6. }

Providers

Zend_Tool_Framework_Provider represents the functional or "capability" aspect of the framework. Fundamentally, Zend_Tool_Framework_Provider will provide the interfaces necessary to produce "providers", or bits of tooling functionality that can be called and used inside the Zend_Tool_Framework toolchain. The simplistic nature of implementing this provider interface allows the developer a "one-stop-shop" of adding functionality or capabilities to Zend_Tool_Framework.

The provider interface is an empty interface and enforces no methods (this is the Marker Interface pattern):

  1. interface Zend_Tool_Framework_Provider_Interface
  2. {}

Or, if you wish, you can implement the base (or abstract) Provider which will give you access to the Zend_Tool_Framework_Registry:

  1. abstract class Zend_Tool_Framework_Provider_Abstract
  2.     implements Zend_Tool_Framework_Provider_Interface,
  3.                Zend_Tool_Registry_EnabledInterface
  4. {
  5.     protected $_registry;
  6.     public function setRegistry(
  7.         Zend_Tool_Framework_Registry_Interface $registry
  8.     );
  9. }

Loaders

The purpose of a Loader is to find Providers and Manifest files that contain classes which implement either Zend_Tool_Framework_Provider_Interface or Zend_Tool_Framework_Manifest_Interface. Once these files are found by a loader, providers are loaded into the Provider Repository and manifest metadata is loaded into the Manifest Repository.

To implement a loader, one must extend the following abstract class:

  1. abstract class Zend_Tool_Framework_Loader_Abstract
  2. {
  3.  
  4.     abstract protected function _getFiles();
  5.  
  6.     public function load()
  7.     {
  8.         /** ... */
  9.     }
  10. }

The _getFiles() method should return an array of files (absolute paths). The built-in loader supplied with Zend Framework is called the IncludePath loader. By default, the Tooling framework will use an include_path based loader to find files that might include Providers or Manifest Metadata objects. Zend_Tool_Framework_Loader_IncludePathLoader, without any other options, will search for files inside the include path that end in Mainfest.php, Tool.php or Provider.php. Once found, they will be tested (by the load() method of the Zend_Tool_Framework_Loader_Abstract) to determine if they implement any of the supported interfaces. If they do, an instance of the found class is instantiated, and it is appended to the proper repository.

  1. class Zend_Tool_Framework_Loader_IncludePathLoader
  2.     extends Zend_Tool_Framework_Loader_Abstract
  3. {
  4.  
  5.     protected $_filterDenyDirectoryPattern = '.*(/|\\\\).svn';
  6.     protected $_filterAcceptFilePattern = '.*(?:Manifest|Provider)\.php$';
  7.  
  8.     protected function _getFiles()
  9.     {
  10.         /** ... */
  11.     }
  12. }

As you can see, the IncludePath loader will search all include_paths for the files that match the $_filterAcceptFilePattern and not match the $_filterDenyDirectoryPattern.

Manifests

In short, the Manifest shall contain specific or arbitrary metadata that is useful to any provider or client, as well as be responsible for loading any additional providers into the provider repository.

To introduce metadata into the manifest repository, all one must do is implement the empty Zend_Tool_Framework_Manifest_Interface, and provide a getMetadata() method which shall return an array of objects that implement Zend_Tool_Framework_Manifest_Metadata.

  1. interface Zend_Tool_Framework_Manifest_Interface
  2. {
  3.     public function getMetadata();
  4. }

Metadata objects are loaded (by a loader defined below) into the Manifest Repository (Zend_Tool_Framework_Manifest_Repository). Manifests will be processed after all Providers have been found to be loaded into the provider repository. This shall allow Manifests to create Metadata objects based on what is currently inside the provider repository.

There are a few different metadata classes that can be used to describe metadata. The Zend_Tool_Framework_Manifest_Metadata is the base metadata object. As you can see by the following code snippet, the base metadata class is fairly lightweight and abstract in nature:

  1. class Zend_Tool_Framework_Metadata_Basic
  2. {
  3.  
  4.     protected $_type        = 'Global';
  5.     protected $_name        = null;
  6.     protected $_value       = null;
  7.     protected $_reference   = null;
  8.  
  9.     public function getType();
  10.     public function getName();
  11.     public function getValue();
  12.     public function getReference();
  13.     /** ... */
  14. }

There are other built in metadata classes as well for describing more specialized metadata: ActionMetadata and ProviderMetadata. These classes will help you describe in more detail metadata that is specific to either actions or providers, and the reference is expected to be a reference to an action or a provider respectively. These classes are described in the following code snippet.

  1. class Zend_Tool_Framework_Manifest_ActionMetadata
  2.     extends Zend_Tool_Framework_Manifest_Metadata
  3. {
  4.  
  5.     protected $_type = 'Action';
  6.     protected $_actionName = null;
  7.  
  8.     public function getActionName();
  9.     /** ... */
  10. }
  11.  
  12. class Zend_Tool_Framework_Manifest_ProviderMetadata
  13.     extends Zend_Tool_Framework_Manifest_Metadata
  14. {
  15.  
  16.     protected $_type = 'Provider';
  17.     protected $_providerName  = null;
  18.     protected $_actionName    = null;
  19.     protected $_specialtyName = null;
  20.  
  21.     public function getProviderName();
  22.     public function getActionName();
  23.     public function getSpecialtyName();
  24.     /** ... */
  25. }

'Type' in these classes is used to describe the type of metadata the object is responsible for. In the cases of the ActionMetadata, the type would be 'Action', and conversely in the case of the ProviderMetadata the type is 'Provider'. These metadata types will also include additional structured information about both the "thing" they are describing as well as the object (the getReference()) they are referencing with this new metadata.

In order to create your own metadata type, all one must do is extend the base Zend_Tool_Framework_Manifest_Metadata class and return these new metadata objects via a local Manifest class or object. These user based classes will live in the Manifest Repository

Once these metadata objects are in the repository, there are then two different methods that can be used in order to search for them in the repository.

  1. class Zend_Tool_Framework_Manifest_Repository
  2. {
  3.     /**
  4.      * To use this method to search, $searchProperties should contain the names
  5.      * and values of the key/value pairs you would like to match within the
  6.      * manifest.
  7.      *
  8.      * For Example:
  9.      *     $manifestRepository->findMetadatas(array(
  10.      *         'action' => 'Foo',
  11.      *         'name'   => 'cliActionName'
  12.      *         ));
  13.      *
  14.      * Will find any metadata objects that have a key with name 'action' value
  15.      * of 'Foo', AND a key named 'name' value of 'cliActionName'
  16.      *
  17.      * Note: to either exclude or include name/value pairs that exist in the
  18.      * search criteria but do not appear in the object, pass a bool value to
  19.      * $includeNonExistentProperties
  20.      */
  21.     public function findMetadatas(Array $searchProperties = array(),
  22.                                   $includeNonExistentProperties = true);
  23.  
  24.     /**
  25.      * The following will return exactly one of the matching search criteria,
  26.      * regardless of how many have been returned. First one in the manifest is
  27.      * what will be returned.
  28.      */
  29.     public function findMetadata(Array $searchProperties = array(),
  30.                                  $includeNonExistentProperties = true)
  31.     {
  32.         $metadatas = $this->getMetadatas($searchProperties,
  33.                                          $includeNonExistentProperties);
  34.         return array_shift($metadatas);
  35.     }
  36. }

Looking at the search methods above, the signatures allow for extremely flexible searching. In order to find a metadata object, simply pass in an array of matching constraints via an array. If the data is accessible through the Property accessor (the getSomething() methods implemented on the metadata object), then it will be passed back to the user as a "found" metadata object.

Clients

Clients are the interface which bridges a user or external tool into the Zend_Tool_Framework system. Clients can come in all shapes and sizes: RPC endpoints, Command Line Interface, or even a web interface. Zend_Tool has implemented the command line interface as the default interface for interacting with the Zend_Tool_Framework system.

To implement a client, one would need to extend the following abstract class:

  1. abstract class Zend_Tool_Framework_Client_Abstract
  2. {
  3.     /**
  4.      * This method should be implemented by the client implementation to
  5.      * construct and set custom loaders, request and response objects.
  6.      *
  7.      * (not required, but suggested)
  8.      */
  9.     protected function _preInit();
  10.  
  11.     /**
  12.      * This method should be implemented by the client implementation to parse
  13.      * out and set up the request objects action, provider and parameter
  14.      * information.
  15.      */
  16.     abstract protected function _preDispatch();
  17.  
  18.     /**
  19.      * This method should be implemented by the client implementation to take
  20.      * the output of the response object and return it (in an client specific
  21.      * way) back to the Tooling Client.
  22.      *
  23.      * (not required, but suggested)
  24.      */
  25.     abstract protected function _postDispatch();
  26. }

As you can see, there 1 method is required to fulfill the needs of a client (two others suggested), the initialization, prehandling and post handling. For a more in depth study of how the command line client works, please see the » source code.

Using the CLI Tool
Zend_Tool_Framework
Programmer's Reference Guide