Weil Provider und Manifeste von überall im include_path kommen können, wird eine Registry angeboten um den Zugriff auf die verschiedenen Teile der Toolchain zu vereinfachen. Diese Registry wird in Komponenten eingefügt die registry-aware sind, und damit Abhängigkeiten entfernen können, wenn das notwendig ist. Die meisten Abhängigkeiten die in der Registry registriert werden sind Unter-Komponenten spezifische Repositories. Das Interface für die Registry besteht aus der folgenden Definition: Die verschiedenen Objekte welche die Registry managt werden in deren betreffenden Kapiteln besprochen. Klassen welche Registry-aware sind sollten Zend_Tool_Framework_Registry_EnabledInterface implementieren. Dieses Interface erlaubt hauptsächlich die Initialisierung der Registry in der Zielklasse. Zend_Tool_Framework_Provider repräsentiert den funktionalen oder "möglichen" Aspekt des Frameworks. Grundsätzlich bietet Zend_Tool_Framework_Provider das Interface um "Provider" zu erstellen, oder Teile für Werkzeug-Funktionalität die aufgerufen werden können und in der Zend_Tool_Framework Toolchain verwendet werden. Die einfache Natur der Implementation dieses Provider Interfaces erlaubt es dem Entwickler ein "One-Stop-Shop" für das Hinzufügen von Funktionalitäten/Möglichkeiten zu Zend_Tool_Framework. Das Provider Interface ist ein leeres Interface und erzwingt keine Methoden (das ist das Marker Interface Pattern): Oder, wenn man das will, kann man den Basis (oder Abstrakten) Provider implementieren, welcher einem Zugriff auf Zend_Tool_Framework_Registry bietet: Der Zweck eines Loaders ist es Provider und Manifest Datei zu finden die Klassen enthalten welche entweder Zend_Tool_Framework_Provider_Interface oder Zend_Tool_Framework_Manifest_Interface implementieren. Sobald diese Dateien vom Loader gefunden wurden, werden die Provider in das Provider Repository geladen und die Manifest Metadaten in das Manifest Repository. Um einen Loader zu implementieren muß man die folgende abstrakte Klasse erweitern: Die _getFiles() Methode sollte ein Array von Dateien zurückgeben (absolute Pfade). Der mit ZF ausgelieferte Loader wird IncludePath Loader genannt. Standardmäßig verwendet das Tooling Framework einen Loader der auf dem Include Pfad basiert um Dateien zu finden die Provider oder Manifest Metadaten Objekte enthalten können. Zend_Tool_Framework_Loader_IncludePathLoader sucht, ohne irgendeine Option, nach Dateien im Include Pfad die mit Mainfest.php, Tool.php oder Provider.php enden. Sobald Sie gefunden wurden, werden Sie (durch die load() Methode von Zend_Tool_Framework_Loader_Abstract) getestet um zu erkennen ob Sie irgendeines der unterstützten Interfaces implementieren. Wenn Sie das tun, wird eine Instanz der gefundenen Klasse instanziiert, und dann dem richtigen Repository angehängt. As you can see, the IncludePath loader will search all include_paths for the files that match the $_filterAcceptFilePattern and NOT match the $_filterDenyDirectoryPattern. 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. Metadata objects are loaded (by a loader defined below) into the Manfiest Repository (Zend_Tool_Framework_Manifest_Repository). Manifests will be processed after all Providers have been found a loaded into the provider repository. This shall allow Manifests to created 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: 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 follow code snippet. '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/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. findMetadatas(array( * 'action' => 'Foo', * 'name' => 'cliActionName' * )); * * Will find any metadata objects that have a key with name 'action' value * of 'Foo', AND a key named 'name' value of 'cliActionName' * * Note: to either exclude or include name/value pairs that exist in the * search critera but do not appear in the object, pass a bool value to * $includeNonExistentProperties */ public function findMetadatas(Array $searchProperties = array(), $includeNonExistentProperties = true); /** * The following will return exactly one of the matching search criteria, * regardless of how many have been returned. First one in the manifest is * what will be returned. */ public function findMetadata(Array $searchProperties = array(), $includeNonExistentProperties = true) { $metadatas = $this->getMetadatas($searchProperties, $includeNonExistentProperties); return array_shift($metadatas); } } ]]> 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 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: As you can see, there is 1 method required to fulfill the needs of a client (two othres suggested), the initialization, prehandling and post handling. For a more in depth study of how the command line client works, please see source code.