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.

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:

class My_Component_HelloProvider
    implements Zend_Tool_Framework_Provider_Interface
{
    public function say($name = 'Ralph')
    {
        echo 'Hallo' . $name . ', von meinem Provider!';
    }
}

Das obige Beispiel kann über die Kommandozeile wie folgt aufgerufen werden: zf say hello Joe. "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 zf say hello weiterhin funktioniert, und der Standardname "Ralph" ist.

Es gibt Fälle in denen der Workflow des Providers es notwendig macht, den Benutzer nach einer Eingabe zu fragen. Das kann getan werden, indem der Client angewiesen wird nach der benötigten Eingabe zu Fragen, indem man folgendes aufruft:

class My_Component_HelloProvider
    extends Zend_Tool_Framework_Provider_Abstract
{
    public function say($name = 'Ralph')
    {
        $nameResponse = $this->_registry
                             ->getClient()
                             ->promptInteractiveInput("Wie ist dein Name?");
        $name = $nameResponse->getContent();

        echo 'Hallo' . $name . ', von meinem Provider!';
    }
}

Dieses Kommando wirft eine Exception wenn der aktuelle Client nicht in der Lage ist die Interaktive Anfrage zu behandeln. Im Fall des standardmäßigen Konsolen Clients wird man trotzdem danach gefragt den Namen einzugeben.

Ein anderes interessantes Feature das man implementieren kann ist Voranstellbarkeit. 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 würde 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.

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.

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!';
        }
    }
}

Um den Provider im vorangestellten Modus auszuführen muss folgendes aufgerufen werden:

% zf --pretend say hello Ralph
I würde zu Ralph hallo sagen.

Man kann Provider Aktionen auch im "verbose" oder "debug" Modus ausführen. Die Semantik in Bezug zu diesen Aktionen muss man selbst im Kontext des eigenen Providers implementieren. Man kann auf die Debug und Verbose Modi wie folgt zugreifen:

class My_Component_HelloProvider
    implements Zend_Tool_Framework_Provider_Interface
{
    public function say($name = 'Ralph')
    {
        if($this->_registry->getRequest()->isVerbose()) {
            echo "Hello::say wurde aufgerufen\n";
        }
        if($this->_registry->getRequest()->isDebug()) {
            syslog(LOG_INFO, "Hello::say wurde aufgerufen\n");
        }
    }
}

Wenn man die Umgebungsvariable ZF_CONFIG_FILE oder .zf.ini im Home Verzeichnis verwendet kann man Konfigurationsparameter in jedem Zend_Tool Provider injizieren. Zugriff auf diese Konfiguration ist über die Registry möglich die dem Provider übergeben wird, wenn man Zend_Tool_Framework_Provider_Abstract erweitert.

class My_Component_HelloProvider
    extends Zend_Tool_Framework_Provider_Abstract
{
    public function say()
    {
        $username = $this->_registry->getConfig()->username;
        if(!empty($username)) {
            echo "Hallo $username!";
        } else {
            echo "Hallo!";
        }
    }
}

Die zurückgegebene Konfiguration ist vom Typ Zend_Tool_Framework_Client_Config, aber intern verweisen die magischen Methoden __get() und __set() auf Zend_Config des angegebenen Konfigurations Typs.

Der Speicher erlaubt es eigene Daten für eine spätere Referenz zu speichern. Das kann für Batch Aufgaben oder für ein erneutes Ausführen von Tasks nützlich sein. Man kann auf den Speicher auf eine ähnliche Art und Weise zugreifen wie auf die Konfiguration:

class My_Component_HelloProvider
    extends Zend_Tool_Framework_Provider_Abstract
{
    public function say()
    {
        $aValue = $this->_registry->getStorage()->get("myUsername");
        echo "Hallo $aValue!";
    }
}

Die API des Speichers ist sehr einfach:

class Zend_Tool_Framework_Client_Storage
{
    public function setAdapter($adapter);
    public function isEnabled();
    public function put($name, $value);
    public function get($name, $defaultValue=null);
    public function has($name);
    public function remove($name);
    public function getStreamUri($name);
}