<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 24249 -->
<!-- Reviewed: no -->
<sect1 id="zend.tool.framework.architecture">
    <title>Architektur</title>

    <sect2 id="zend.tool.framework.architecture.registry">
        <title>Registry</title>

        <para>
            Weil Provider und Manifeste von überall im <property>include_path</property> 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.
        </para>

        <para>
            Das Interface für die Registry besteht aus der folgenden Definition:
        </para>

        <programlisting language="php"><![CDATA[
interface Zend_Tool_Framework_Registry_Interface
{
    public function setClient(Zend_Tool_Framework_Client_Abstract $client);
    public function getClient();
    public function setLoader(Zend_Tool_Framework_Loader_Abstract $loader);
    public function getLoader();
    public function setActionRepository(
        Zend_Tool_Framework_Action_Repository $actionRepository
    );
    public function getActionRepository();
    public function setProviderRepository(
        Zend_Tool_Framework_Provider_Repository $providerRepository
    );
    public function getProviderRepository();
    public function setManifestRepository(
        Zend_Tool_Framework_Manifest_Repository $manifestRepository
    );
    public function getManifestRepository();
    public function setRequest(Zend_Tool_Framework_Client_Request $request);
    public function getRequest();
    public function setResponse(Zend_Tool_Framework_Client_Response $response);
    public function getResponse();
}
]]></programlisting>

        <para>
            Die verschiedenen Objekte welche die Registry managt werden in deren betreffenden
            Kapiteln besprochen.
        </para>

        <para>
            Klassen welche Registry-aware sind sollten
            <classname>Zend_Tool_Framework_Registry_EnabledInterface</classname> implementieren.
            Dieses Interface erlaubt hauptsächlich die Initialisierung der Registry in der
            Zielklasse.
        </para>

        <programlisting language="php"><![CDATA[
interface Zend_Tool_Framework_Registry_EnabledInterface
{
    public function setRegistry(
        Zend_Tool_Framework_Registry_Interface $registry
    );
}
]]></programlisting>
    </sect2>

    <sect2 id="zend.tool.framework.architecture.providers">
        <title>Provider</title>

        <para>
            <classname>Zend_Tool_Framework_Provider</classname> repräsentiert den funktionalen oder
            "möglichen" Aspekt des Frameworks. Grundsätzlich bietet
            <classname>Zend_Tool_Framework_Provider</classname> das Interface um "Provider" zu
            erstellen, oder Teile für Werkzeug-Funktionalität die aufgerufen werden können und in
            der <classname>Zend_Tool_Framework</classname> 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 oder Möglichkeiten zu
            <classname>Zend_Tool_Framework</classname>.
        </para>

        <para>
            Das Provider Interface ist ein leeres Interface und erzwingt keine Methoden
            (das ist das Marker Interface Pattern):
        </para>

        <programlisting language="php"><![CDATA[
interface Zend_Tool_Framework_Provider_Interface
{}
]]></programlisting>

        <para>
            Oder, wenn man das will, kann man den Basis (oder Abstrakten) Provider implementieren,
            welcher einem Zugriff auf <classname>Zend_Tool_Framework_Registry</classname> bietet:
        </para>

        <programlisting language="php"><![CDATA[
abstract class Zend_Tool_Framework_Provider_Abstract
    implements Zend_Tool_Framework_Provider_Interface,
               Zend_Tool_Registry_EnabledInterface
{
    protected $_registry;
    public function setRegistry(
        Zend_Tool_Framework_Registry_Interface $registry
    );
}
]]></programlisting>
    </sect2>

    <sect2 id="zend.tool.framework.architecture.loaders">
        <title>Loader</title>

        <para>
            Der Zweck eines Loaders ist es Provider und Manifest Datei zu finden die Klassen
            enthalten welche entweder <classname>Zend_Tool_Framework_Provider_Interface</classname>
            oder <classname>Zend_Tool_Framework_Manifest_Interface</classname> implementieren.
            Sobald diese Dateien vom Loader gefunden wurden, werden die Provider in das Provider
            Repository geladen und die Manifest Metadaten in das Manifest Repository.
        </para>

        <para>
            Um einen Loader zu implementieren muß man die folgende abstrakte Klasse erweitern:
        </para>

        <programlisting language="php"><![CDATA[
abstract class Zend_Tool_Framework_Loader_Abstract
{

    abstract protected function _getFiles();

    public function load()
    {
        /** ... */
    }
}
]]></programlisting>

        <para>
            Die <methodname>_getFiles()</methodname> Methode sollte ein Array von Dateien
            zurückgeben (absolute Pfade). Der mit Zend Framework 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.
            <classname>Zend_Tool_Framework_Loader_IncludePathLoader</classname> sucht, ohne
            irgendeine Option, nach Dateien im Include Pfad die mit
            <filename>Mainfest.php</filename>, <filename>Tool.php</filename> oder
            <filename>Provider.php</filename> enden. Sobald Sie gefunden wurden, werden Sie (durch
            die <methodname>load()</methodname> Methode von
            <classname>Zend_Tool_Framework_Loader_Abstract</classname>) 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.
        </para>

        <programlisting language="php"><![CDATA[
class Zend_Tool_Framework_Loader_IncludePathLoader
    extends Zend_Tool_Framework_Loader_Abstract
{

    protected $_filterDenyDirectoryPattern = '.*(/|\\\\).svn';
    protected $_filterAcceptFilePattern = '.*(?:Manifest|Provider)\.php$';

    protected function _getFiles()
    {
        /** ... */
    }
}
]]></programlisting>

        <para>
            Wie man sieht, durchsucht der IncludePath Loader alle include_paths nach den Dateien
            die <varname>$_filterAcceptFilePattern</varname> entsprechen und
            <varname>$_filterDenyDirectoryPattern</varname> <emphasis>nicht</emphasis> entsprechen.
        </para>
    </sect2>

    <sect2 id="zend.tool.framework.architecture.manifests">
        <title>Manifests</title>

        <para>
            Kurz gesagt, sollte ein Manifest spezielle oder eigene Metadaten enthalten, die für
            jeden Provider oder Client nützlich sind, sowie dafür verantwortlich sein alle
            zusätzlichen Provider in das Provider Repository zu laden.
        </para>

        <para>
            Um Metadaten in ein Manifest Repository einzuführen, müssen alle das leere
            <classname>Zend_Tool_Framework_Manifest_Interface</classname> implementieren, und eine
            <methodname>getMetadata()</methodname> Methode anbieten die ein Array von Objekten
            zurückgeben sollte, welches
            <classname>Zend_Tool_Framework_Manifest_Metadata</classname> implementiert.
        </para>

        <programlisting language="php"><![CDATA[
interface Zend_Tool_Framework_Manifest_Interface
{
    public function getMetadata();
}
]]></programlisting>

        <para>
            Metadaten Objekte werden in das Manifest Repository
            (<classname>Zend_Tool_Framework_Manifest_Repository</classname>) geladen (durch einen
            wie unten definierten Loader). Manifeste werden ausgeführt nachdem alle Provider
            gefunden und in das Provider Repository geladen wurden. Das sollte es Manifeste
            erlauben Metadaten Objekte, basierend auf dem was aktuell im Provider Repository ist,
            zu erstellen.
        </para>

        <para>
            Es gibt ein paar andere Metadaten Klassen die dazu verwendet werden können um Metadaten
            zu beschreiben. <classname>Zend_Tool_Framework_Manifest_Metadata</classname> ist das
            Basis Metadaten Objekt. Wie man durch das folgende Code Snippet sieht, ist die
            grundsätzliche Metadaten Klasse recht leichtgewichtig und von Natur aus abstrakt:
        </para>

        <programlisting language="php"><![CDATA[
class Zend_Tool_Framework_Manifest_Basic
{

    protected $_type        = 'Global';
    protected $_name        = null;
    protected $_value       = null;
    protected $_reference   = null;

    public function getType();
    public function getName();
    public function getValue();
    public function getReference();
    /** ... */
}
]]></programlisting>

        <para>
            Es gibt andere eingebaute Metadaten Klassen für das beschreiben von spezialisierteren
            Metadaten: <classname>ActionMetadata</classname> und
            <classname>ProviderMetadata</classname>. Diese Klassen helfen dabei Metadaten
            detailierter zu beschreiben die spezifisch für Actions oder Provider ist, und von der
            Referenz wird erwartet das Sie entweder eine Referenz zu einer Action oder einem
            Provider ist. Diese Klassen werden im folgenden Code Snippet beschrieben.
        </para>

        <programlisting language="php"><![CDATA[
class Zend_Tool_Framework_Manifest_ActionMetadata
    extends Zend_Tool_Framework_Manifest_Metadata
{

    protected $_type = 'Action';
    protected $_actionName = null;

    public function getActionName();
    /** ... */
}

class Zend_Tool_Framework_Manifest_ProviderMetadata
    extends Zend_Tool_Framework_Manifest_Metadata
{

    protected $_type = 'Provider';
    protected $_providerName  = null;
    protected $_actionName    = null;
    protected $_specialtyName = null;

    public function getProviderName();
    public function getActionName();
    public function getSpecialtyName();
    /** ... */
}
]]></programlisting>

        <para>
            Der 'Type' in diesen Klassen wird verwendet um den Typ der Metadaten zu beschreiben
            für den das Objekt verantwortlich ist. Im Fall von
            <classname>ActionMetadata</classname> würde der Typ 'Action' sein, und für
            <classname>ProviderMetadata</classname> ist der Typ natürlich 'Provider'. Diese
            Typen der Metadaten werden enthalten auch zusätzliche strukturierte Informationen,
            sowohl über das "Ding" das Sie beschreiben, als auch über das Objekt (das
            <methodname>getReference()</methodname> ) auf das Sie mit diesen neuen Metadaten
            referenzieren.
        </para>

        <para>
            Um einen eigenen Metadaten Typ zu erstellen, müssen alle die grundsätzliche
            <classname>Zend_Tool_Framework_Manifest_Metadata</classname> Klasse erweitern und diese
            neuen Metadaten Objekte über die lokale Manifest Klasse oder das Objekt zurückgeben.
            Diese Benutzerbasierten Klassen werden alle im Manifest Repository leben.
        </para>

        <para>
            Sobald diese Metadaten Objekte im Repository sind gibt es zwei unterschiedliche
            Methoden die verwendet werden können um nach Ihnen im Repository zu suchen.
        </para>

        <programlisting language="php"><![CDATA[
class Zend_Tool_Framework_Manifest_Repository
{
    /**
     * To use this method to search, $searchProperties should contain the names
     * and values of the key/value pairs you would like to match within the
     * manifest.
     *
     * For Example:
     *     $manifestRepository->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);
    }
}
]]></programlisting>

        <para>
            Wenn man sich die Suchmethoden von oben anschaut, erlauben die Signaturen eine extrem
            flexible Suche. Um ein Metadaten Objekt zu finden, muss man einfach ein Array von
            passenden Abhängigkeiten über ein Array anhängen. Wenn auf die Daten über den Property
            Accessor zugegriffen werden kann (die <methodname>getSomething()</methodname> Methoden
            implementieren das Metadaten Objekt), dann wird es an den Benutzer als "gefundenes"
            Metadaten Objekt zurück gegeben.
        </para>
    </sect2>

    <sect2 id="zend.tool.framework.architecture.clients">
        <title>Clienten</title>

        <para>
            Clienten sind das Interface welches einen Benutzer oder ein externes Tool in das
            System von <classname>Zend_Tool_Framework</classname> verknüpft. Clienten können in
            allen Formen und Größen vorkommen: <acronym>RPC</acronym> Endpunkte, Kommandozeilen
            Interface, oder sogar ein Web Interface. <classname>Zend_Tool</classname> hat das
            Kommandozeilen Interface als standard Interface für die Interaktion mit dem
            <classname>Zend_Tool_Framework</classname> System implementiert.
        </para>

        <para>
            Um einen Client zu implementieren, muss man die folgende abstrakte Klasse erweitern:
        </para>

        <programlisting language="php"><![CDATA[
abstract class Zend_Tool_Framework_Client_Abstract
{
    /**
     * This method should be implemented by the client implementation to
     * construct and set custom loaders, request and response objects.
     *
     * (not required, but suggested)
     */
    protected function _preInit();

    /**
     * This method should be implemented by the client implementation to parse
     * out and setup the request objects action, provider and parameter
     * information.
     */
    abstract protected function _preDispatch();

    /**
     * This method should be implemented by the client implementation to take
     * the output of the response object and return it (in an client specific
     * way) back to the Tooling Client.
     *
     * (not required, but suggested)
     */
    abstract protected function _postDispatch();
}
]]></programlisting>

        <para>
            Wie man sieht gibt es 1 Methode benötigte Methode um die Notwendigkeiten eines
            Cliente zu erfüllen (zwei andere sind empfohlen), die Initialisierung, Vorbehandlung
            (pre handling) und Nachbehandlung (post handling). Für eine tiefere Studie darüber wie
            das Kommandozeilen Interface arbeitet, schauen Sie bitte im <ulink
                url="http://framework.zend.com/svn/framework/standard/trunk/library/Zend/Tool/Framework/Client/Console.php">Source
                Code</ulink>.
        </para>
    </sect2>
</sect1>