Das CLI, oder Kommandozeilentool (intern bekannt als Konsolen Tool), ist aktuell das primäre Interface für die Bearbeitung von Zend_Tool Anfragen. Mit dem CLI Tool können Entwickler Tooling Anfragen im "Kommandozeilen Fenster", auch bekannt als "Terminal" Fenster, auslösen. Diese Umgebung ist vorherrschend bei *nix Umgebungen, es gibt aber auch übliche Implementationen unter Windows mit cmd.exe, Console2 und auch im Cygwin Projekt. Zuerst muss Zend Framework heruntergeladen werden. Dazu geht man auf die Seite framework.zend.com und lädt das letzte Release herunter. Nachdem man das Paket heruntergeladen und auf dem System plaziert hat, ist der nächste Schritt das zf Kommendo auf dem System zu erstellen. Der einfachste Weg dafür ist, die richtigen Dateien vom bin/ Verzeichnis des Downloads zu kopieren, und diese Dateien im gleichen Verzeichnis zu platzieren wie die PHP CLI Binardatei. Um es über PEAR zu installieren, muss man die 3rd Party Site zfcampus.org verwenden um das letzte Zend Framework PEAR Paket zu installieren. Diese Pakete werden typischerweise innerhalb eines Tages nach einem offiziellen Zend Framework Release erstellt. Der Vorteil der Installation über den PEAR Package Manager ist, dass die ZF Bibliothek im include_path landet, und die zf.php und ZF Skripte an einem Ort im eigenen System landen, der es erlaubt sie ohne zusätzliches Setup zu starten. Das ist es schon. Nach dem initialen Setup sollte man in der Lage sein, weiter zu machen indem das zf Kommando ausgeführt wird. Ein guter Weg um zu prüfen, ob es vorhanden ist, ist es zf --help auszuführen. Die Installtion von Hand zeigt das Verfahren, wie zf.php und die Zend Framework Bibliothek dazu gebracht werden zusammen zu arbeiten, wenn diese nicht an konventionellen Orten abgelegt wurden, oder zumindest, an einem Ort an dem das eigene System diese nicht einfach ausführen kann (was normalerweise für Programme im eigenen System Pfad gilt). Wenn man auf einem *nix oder Mac System ist, kann man auch einen Link von irgendwo im eigenen Pfad zur zf.sh Datei erstellen. Dabei muss man sich keine Gedanken darüber machen, ob die Zend Framework Bibliothek im eigenen include_path ist, da die Dateien zf.php und zf.sh auf die Bibliothek zugreifen können, relativ zu deren Standort, (was bedeutet das die ./bin/ Dateien relativ zu ../library/ der Zend Framework Bibliothek sind). Es gibt eine Anzahl von anderen vorhandenen Optionen für das Setup von zf.php und der Bibliothek im eigenen System. Diese Optionen drehen sich um das Setzen von speziellen Umgebungsvariablen. Diese werden im späteren Kapitel "Die CLI Umgebung anpassen" beschrieben. Die Umgebungsvariablen für das Setzen von include_path, ZF_INCLUDE_PATH und ZF_INCLUDE_PATH_PREPEND für zf.php sind die interessantesten. Das zeigt die aktuelle Versionsnummer der Kopie des Zend Framework, welche das zf.php Tool verwendet. Das eingebaute Hilfesystem ist der erste Ort an dem man aktuelle Informationen darüber erhält, was das eigene System in der Lage ist zu tun. Das Hilfesystem ist dahingehend dynamisch, dass Provider dem eigenen System hinzugefügt und automatisch ausgeführt werden, und von daher werden die für die Ausführung notwendigen Parameter im Hilfebildschirm vorhanden. Der einfachste Weg um den Hilfebildschirm zu erhalten, ist der folgende: Das gibt einen Überblick über die verschiedenen Möglichkeiten des Systems. Manchmal gibt es komplexere Kommandos, die ausgeführt werden können, und um mehr Informationen über sie zu erhalten, muss man einen spezielles Hilfebefehl ausführen. Für die spezialisierte Hilfe muss einfach eines der Elemente des Kommandos mit einem "?" ersetzt werden. Das sagt dem Hilfesystem, dass man mehr Informationen darüber will, welche Kommandos an Stelle des Fragezeichens stehen können. Zum Beispiel: Das obige bedeutet "zeig mir alle 'Aktionen' für den Provider 'controller'"; während das folgende: bedeutet "zeig mit alle Provider welche die 'show' Aktion unterstützen. Das funktioniert auch, wenn man es für Optionen anwendet, wie man im folgenden Beispiel sehen kann: Das zeigt welche Informationen im Tooling System Manifest sind. Das ist wichtiger für Entwickler von Providers als für normale Benutzer des Tooling Systems. Der Projekt-Provider ist das erste Kommando, das man ausführen könnte. Er erstellt die grundsätzliche Struktur der Anwendung. Er wird benötigt, bevor irgendein anderer Provider ausgeführt werden kann. Dies erstellt ein Projekt im ./MyProjectName genannten Verzeichnis. Von diesem Punkt an, ist es wichtig anzumerken, dass jedes weitere Kommando in der Kommandozeile von innerhalb des Projektverzeichnisses auszuführen ist, welches gerade erstellt wurde. Nach dessen Erstellung ist es also notwendig, dass man in das Verzeichnis wechselt. Der Module Provider erlaubt die einfache Erstellung eines Zend Framework Moduls. Ein Modul folgt lose dem MVC Pattern. Wenn Module erstellt werden, verwenden sie die gleiche Struktur, welche im application/ Level verwendet wird, und dupliziert diese im ausgewählten Namen für das Modul, innerhalb des Verzeichnisses "modules" im Verzeichnis application/ ohne dass das Modul Verzeichnis selbst dupliziert wird. Zum Beispiel: Das erstellt ein Modul welches Blog genannt wird unter application/modules/Blog, und alle Abschnitte welche das Modul benötigt. Der Controller Provider ist (meistens) für die Erstellung leerer Controller zuständig sowie deren entsprechenden Verzeichnissen und Dateien für View Skripte. Um ihn zum Beispiel dazu zu verwenden, einen 'Auth' Controller zu erstellen, muss folgendes ausgeführt werden: Das erstellt einen Controller der Auth heißt, und im speziellen wird eine Datei unter application/controllers/AuthController.php erstellt, welche den AuthController enthält. Wenn man einen Controller für ein Modul erstellen will, kann eine der folgenden Zeilen verwendet werden: Beachte: Im ersten Kommando ist der Wert 1 für das "includeIndexAction" Flag. Um eine Action in einem bestehenden Controller zu erstellen: Um eine View ausserhalb der normalen Controller/Action Erstellung zu erstellen würde man eine der folgenden Zeilen verwenden: Das erstellt ein View Skript im Controller Verzeichnis von Auth. Der Model Provider ist nur für die Erstellung der richtigen Modell Dateien, mit dem richtigen Namen im Anwendungsverzeichnis zuständig. Zum Beispiel: Wenn man ein Modell mit einem spezifischen Modul erstellen will: Das obige erstellt ein 'Post' Modell im Modul 'Blog'. Der Form Provider ist nur für die Erstellung der richtigen Formulardateien und der init() Methode, mit dem richtigen Namen im Anwendungsverzeichnis zuständig. Zum Beispiel: Wenn man ein Modell in einem spezifischen Modul erstellen will: Das obige erstellt ein 'Comment' Formular im Modul 'Blog'. Um einen DbAdapter zu konfigurieren muss man die Informationen als Url kodierten String angeben. Dieser String muss in der Kommandozeile in Hochkommas stehen. Um zum Beispiel die folgenden Informationen einzugeben: adapter: Pdo_Mysql username: test password: test dbname: test Muss das folgende auf der Kommandozeile ausgeführt werden: Dies nimmt an das man diese Information im Abschnitt 'production' der Konfigurationsdatei der Anwendung speichern will. Das folgende demonstriert eine Sqlite Konfiguration im Abschnitt 'development' der Konfigurationsdatei der Anwendung: Der DbTable Provider ist für die Erstellung der Zend_Db_Table Modell/Datenzugriffs-Dateien, der Anwendung die sie benötigt, verantwortlich. Zusammen mit dem richtigen Klassennamen und dem richtigen Platz in der Anwendung. Die zwei wichtigsten Informationsteile sind DbTable Name und der aktuelle Name der Datenbank Tabelle. Zum Beispiel: Der DbTable Provider ist auch dazu in der Lage die richtigen Daten zu erstellen indem er die Datenbank scannt, die mit dem obigen DbAdapter Provider konfiguriert wurde. Wenn das obenstehende ausgeführt wird, könnte es Sinn machen das Vortäuschen-Flag ("-p") zuerst zu verwenden, damit man sieht, was getan werden würde und welche Tabellen in der Datenbank gefunden werden können. Aktuell ist die einzige unterstützte Aktion für Layouts einfach deren Aktivierung, damit die richtigen Schlüssel in die Datei application.ini geschrieben werden damit die Anwendungs Ressource funktioniert und die richtigen Verzeichnisse und die Datei layout.phtml erstellt wird. Das Speicherverzeichnis ist wichtig, damit Provider einen Platz haben, an dem sie die Benutzer-definierte Logik finden, welche die Art verändern könnte, wie sie sich verhalten. Ein Beispiel welches unten angegeben ist, bewirkt die Platzierung einer eigenen Projekt Profil Datei. Das erstellt die richtige zf.ini Datei. Dies sollte nach zf --setup storage-directory ausgeführt werden. Wenn dem nicht so ist, wird sie im Home-Verzeichnis des Benutzers platziert. Aber wenn dem so ist, dann wird sie im benutzerdefinierten Speicherverzeichnis platziert. Diese sollten gesetzt werden, wenn man die standardmäßigen Orte überschreiben will, an denen ZF versucht seine Werte zu lesen. ZF_HOME Das Verzeichnis, in dem dieses Tool nach dem Home-Verzeichnis nachsieht Das Verzeichnis muss existieren Suchrichtung: ZF_HOME Umgebungsvariable HOME Umgebungsvariable dann HOMEPATH Umgebungsvariable ZF_STORAGE_DIRECTORY Wo dieses Tool nach dem Speicherverzeichnis nachsehen wird Das Verzeichnis muss existieren Suchrichtung: ZF_STORAGE_DIRECTORY Umgebungsvariable $homeDirectory/.zf/ Verzeichnis ZF_CONFIG_FILE Wo dieses Tool nach der Konfigurationsdatei nachsieht Suchrichtung: ZF_CONFIG_FILE Umgebungsvariable $homeDirectory/.zf.ini Datei wenn sie existiert $storageDirectory/zf.ini Datei wenn sie existiert ZF_INCLUDE_PATH Setzt den include_path der für dieses Tool verwendet werden soll auf diesen Wert Originales Verhalten: Verwende include_path von PHP um ZF zu finden Verwende die Umgebungsvariable ZF_INCLUDE_PATH Verwende den Pfad ../library (relativ zu zf.php) um ZF zu finden ZF_INCLUDE_PATH_PREPEND Stellt diesen Wert dem aktuellen include_path in php.ini voran