repo_zf1/documentation/manual/de/module_specs/Zend_Tool_Framework-WritingProviders.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 16656 -->
<!-- Reviewed: no -->
<sect1 id="zend.tool.framework.writing-providers">
    <title>Erstellen von Providern für die Verwendung mit Zend_Tool_Framework</title>

    <para>
        Generell ist ein Provider für sich selbst nichts mehr als die Shell für einen Entwickler
        um einige Fähigkeiten zu bündeln die man mit dem Kommandozeilen (oder einem anderen)
        Client ausliefern will. Das ist analog zu dem was ein "Controller" in einer
        <acronym>MVC</acronym> Anwendung ist.
    </para>

    <sect2 id="zend.tool.framework.writing-providers.basic">
        <title>Grundsätzliche Anweisungen für die Erstellung von Providern</title>

        <para>
            Wenn, als Beispiel, ein Entwickler die Fähigkeit hinzufügen will, die Version einer
            Datendatei anzuzeigen, mit der seine 3rd Party Komponente arbeitet, gibt es nur eine
            Klasse die der Entwickler implementieren muss. Angenommen die Komponente heisst
            <classname>My_Component</classname>, dann würde er eine Klasse erstellen die
            <classname>My_Component_HelloProvider</classname> heisst und in einer Datei ist die
            <filename>HelloProvider.php</filename> heisst und irgendwo im
            <property>include_path</property> ist. Diese Klasse würde
            <classname>Zend_Tool_Framework_Provider_Interface</classname> implementieren, und der
            Body dieser Datei würde nur wie folgt auszusehen haben:
        </para>

        <programlisting language="php"><![CDATA[
class My_Component_HelloProvider
    implements Zend_Tool_Framework_Provider_Interface
{
    public function say()
    {
        echo 'Hallo von meinem Provider!';
    }
}
]]></programlisting>

        <para>
            Durch den obigen Code, und der Annahme das der Entwickler den Zugriff auf diese
            funktionalität über den Consolen Client will, würde der Aufruf wie folgt aussehen:
        </para>

        <programlisting language="sh"><![CDATA[
% zf say hello
Hello from my provider!
]]></programlisting>
    </sect2>

    <sect2 id="zend.tool.framework.writing-providers.advanced">
        <title>Fortgeschrittene Informationen für die Entwicklung</title>

        <para>
            Das obige "Hello World" Beispiel ist perfekt für einfache Kommandos, aber was ist mit
            etwas fortgeschrittenerem? Wenn das Scripting und Tooling wächst, kann die
            Notwendigkeit entstehen Variablen zu akzeptieren. So wie Signaturen von Funktionen
            Parameter haben, kann eine Tooling Anfrage auch Parameter akzeptieren.
        </para>

        <para>
            So wie jede Tooling Anfrage in einer Methode in einer Klasse isoliert werden kann,
            können die Parameter einer Tooling Anfrage auch in einem sehr bekannten Platz isoliert
            werden. Parameter von Action Methoden eines Providers können die selben Parameter
            enthalten die man im Client verwenden will, wenn man den Namen im obigen Beispiel
            akzeptieren will, und man würde das in OO Code warscheinlich wie folgt tun:
        </para>

        <programlisting language="php"><![CDATA[
class My_Component_HelloProvider
    implements Zend_Tool_Framework_Provider_Interface
{
    public function say($name = 'Ralph')
    {
        echo 'Hallo' . $name . ', von meinem Provider!';
    }
}
]]></programlisting>

        <para>
            Das obige Beispiel kann pber di Kommandozeile wie folgt aufgerufen werden:
            <command>zf say hello Joe</command>. "Joe" wird dem Provider als Parameter des
            Methodenaufrufs zur Verfügung gestellt. Es ist auch zu beachten das der Parameter
            optional ist, was bedeutet das er auch auf der Kommandozeile optional ist, so das
            <command>zf say hello</command> weiterhin funktioniert, und der Standardname "Ralph"
            ist.
        </para>

        <para>
            Ein anderes interessantes Feature das man implementieren kann ist
            <emphasis>Voranstellbarkeit</emphasis>. Voranstellbarkeit ist die Fähigkeit des
            Providers "Voranzustellen" wie wenn er die angefragte Aktion und Provider
            Kombination ausführt, und dem Benutzer so viel Information wie möglich darüber gibt
            was er tun <emphasis>würde</emphasis> ohne es wirklich zu tun. Das kann eine wichtige
            Option sein wenn viele Datenbank oder Dateisystem Änderungen durchzuführen sind, die
            der Benutzer andernfalls nicht tun würde.
        </para>

        <para>
            Voranstellbarkeit ist einfach zu implementieren. Es gibt zwei Teile dieses Features:
            1) Markieren des Providers, das er die Fähigkeit des "voranstellens" hat und 2) prüfen
            der Anfrage um Sicherzustellen das die aktuelle Anfrage wirklich das "voranstellen"
            angefragt hat. Dieses Feature wird im nächsten Code Beispiel demonstriert.
        </para>

        <programlisting language="php"><![CDATA[
class My_Component_HelloProvider
    extends    Zend_Tool_Framework_Provider_Abstract
    implements Zend_Tool_Framework_Provider_Pretendable
{
    public function say($name = 'Ralph')
    {
        if ($this->_registry->getRequest()->isPretend()) {
            echo 'Ich würde zu ' . $name . ' hallo sagen.';
        } else {
            echo 'Hallo' . $name . ', von meinem Provider!';
        }
    }
}
]]></programlisting>
    </sect2>
</sect1>