Viele Entwickler suchen Hilfe für die beste Projektstruktur für ein Zend Framework Projekt in einer relativ flexiblen Umgebung. Eine "flexible" Umgebung ist eine, in welcher der Entwickler seine Dateisysteme und Konfigurationen des Webservers wie benötigt manipulieren kann, um die ideale Projektstruktur zu erhalten, damit die Anwendungen ausgeführt werden können und sicher sind. Die standardmäßige Projektstruktur stellt sicher, dass der Entwickler diese Flexibilität zu seiner Verfügung hat. Die folgende Verzeichnisstruktur ist für komplexe Projekte maximal erweiterbar, wärend sie eine einfache Teilmenge von Verzeichnissen und Dateien für Projekte mit einfacheren Anforderungen anbietet. Diese Struktur funktioniert auch ohne Änderung sowohl für modulare und nicht-modulare Zend Framework Anwendungen. Die .htaccess-Dateien benötigen URL Rewrite Funktionalität im Web Server wie im Leitfaden für die Rewrite Konfiguration beschrieben, der auch in diesem Anhang enthalten ist. Es ist nicht angedacht, dass diese Projektstruktur alle möglichen Anforderungen für Zend Framework Projekte unterstützt. Das standardmäßige Projektprofil, welches von Zend_Tool verwendet wird, reflektiert diese Projektstruktur. Aber Anwendungen mit Anforderungen, die nicht von dieser Struktur unterstützt werden, sollten ein angepasstes Projektprofil verwenden. / application/ configs/ application.ini controllers/ helpers/ forms/ layouts/ filters/ helpers/ scripts/ models/ modules/ services/ views/ filters/ helpers/ scripts/ Bootstrap.php data/ cache/ indexes/ locales/ logs/ sessions/ uploads/ docs/ library/ public/ css/ images/ js/ .htaccess index.php scripts/ jobs/ build/ temp/ tests/ ]]> Nachfolgend ist der Verwendungszweck für jedes Verzeichnis aufgeführt. application/: Das Verzeichnis enthält die eigentliche Anwendung. Das wird das MVC System einschliessen, sowie Konfigurationen, verwendete Services, und die eigene Bootstrap Datei. configs/: Das anwendungsweite Konfigurationsverzeichnis. controllers/, models/, und views/: Diese Verzeichnisse fungieren als Standardcontroller, Modell oder View Verzeichnisse. Diese drei Verzeichnisse im Anwendungsverzeichnis zu haben bietet das beste Layout für das Starten eines einfachen Projekts sowie als Start eines modularen Projekts das globale controllers/models/views hat. controllers/helpers/: Diese Verzeichnisse enthalten Action Helfer. Action Helfer haben entweder einen Namespace von "Controller_Helper_" im Standardmodul oder "<Module>_Controller_Helper" in anderen Modulen. layouts/: Dieses Layout Verzeichnis ist für MVC-basierte Layouts. Da Zend_Layout in der Lage ist MVC- und nicht-MVC-basierte Layouts zu verstehen, zeigt der Ort dieses Verzeichnisses das Layouts keine 1-zu-1 beziehung zu Controllern haben und unabhängig von Templates in views/ sind. modules/: Module erlauben einem Entwickler ein Set von zusammengehörenden Controllern in eine logisch organisierte Gruppe zu gruppieren. Die Struktur im Modules Verzeichnis würde die Struktur des Application Verzeichnisses haben. services/: Dieses Verzeichnis ist für eigene anwendungsspezifische Web-Service Dateien, welche von der eigenen Anwendung angeboten werden, oder für die Implementierung eines Service Layers für eigene Modelle. Bootstrap.php: Diese Datei ist der Eistiegspunkt für die eigene Anwendung, und sollte Zend_Application_Bootstrap_Bootstrapper implementieren. Das Ziel dieser Datei ist es, die Anwendung zu starten und Komponenten der Anwendung zur Verfügung zu stellen, indem diese initialisiert werden. data/: Dieses Verzeichnis bietet einen Ort an dem Anwendungsdaten gespeichert werden, die angreifbar und möglicherweise temporär sind. Die Veränderung von Daten in diesem Verzeichnis kann dazu führen, dass die Anwendung fehlschlägt. Die Informationen in diesem Verzeichnis können, oder auch nicht, in ein Subversion Repository übertragen werden. Beispiele von Dingen in diesem Verzeichnis sind Session Dateien, Cache Dateien, SQLite Datenbanken, Logs und Indizes. docs/: Dieses Verzeichnis enthält die Dokumentation, entweder erzeugt oder direkt bearbeitet. library/: Dieses Verzeichnis ist für übliche Bibliotheken, von denen die Anwendung abhängt, und es sollte im include_path von PHP sein. Entwickler sollten den Bibliotheks-Code ihrer Anwendung in diesem Verzeichnis, unter einem eindeutigen Namespace platzieren, und den Richtlinien folgen, die im Handbuch von PHP unter Userland Naming Guide beschrieben sind, sowie denen, die von Zend selbst beschrieben sind. Dieses Verzeichnis kann auch das Zend Framework selbst enthalten; wenn dem so ist, würde es unter library/Zend/ platziert werden. public/: Dieses Verzeichnis enthält alle öffentlichen Dateien für die eigene Anwendung. index.php konfiguriert und startet Zend_Application, welche seinerseits die Datei application/Bootstrap.php startet, was dazu führt, dass der Front Controller ausgeführt wird. Das DocumentRoot des Web Server sollte typischerweise auf dieses Verzeichnis gesetzt sein. scripts/: Dieses Verzeichnis enthält Maintenance und/oder Build Skripte. Solche Skripte können Commandline, Cron oder Phing Build Skripte enthalten, die nicht wärend der Laufzeit ausgeführt werden, aber Teil für das korrekte Funktionieren der Anwendung sind. temp/: Das temp/ Verzeichnis wird für vergängliche Anwendungsdaten verwendet. Diese Information würde typischerweise nicht im SVN Repository der Anwendung gespeichert werden. Wenn Daten im temp/ Verzeichnis gelöscht werden, sollten Anwendungsen dazu in der Lage sein, weiterhin zu laufen, wärend das möglicherweise die Geschwindigkeit reduziert bis die Daten wieder gespeichert oder neu gecacht sind. tests/: Dieses Verzeichnis enthält Anwendungstests. Diese würden hand-geschrieben sein, PHPUnit Tests, Selenium-RC basierte Tests oder basierend auf anderen Test Frameworks. Standardmäßig kann Library Code getestet werden, indem die Verzeichnisstruktur des library/ Verzeichnisses vorgegaukelt wird. Zusätzliche funktionale Tests für die eigene Anwendung können geschrieben werden, indem die Verzeichnisstruktur von application/ vorgegaukelt wird (inklusive der Unterverzeichnisse der Anwendung). Die Verzeichnisstruktur für Module sollte jener des application/ Verzeichnisses in der vorgeschlagenen Projektstruktur entsprechen: / configs/ application.ini controllers/ helpers/ forms/ layouts/ filters/ helpers/ scripts/ models/ services/ views/ filters/ helpers/ scripts/ Bootstrap.php ]]> Der Zweck dieses Verzeichnisse bleibt exakt der gleiche wie der für die vorgeschlagene Verzeichnisstruktur des Projekts. URL Rewriting ist eine der üblichen Funktionen von HTTP Servern. Trotzdem unterscheiden sich die Regeln und die Konfiguration zwischen ihnen sehr stark. Anbei sind einige der üblichen Vorschläge für eine Vielzahl der populären Webserver zu finden, die zur der Zeit in der das hier geschrieben wurde, vorhanden sind. Alle folgenden Beispiel verwenden mod_rewrite, ein offizielles Modul, das zusammen mit Apache kommt. Um es zu verwenden, muss mod_rewrite entweder wärend der Zeit des Kompilierens enthalten sein, oder als Dynamic Shared Objekt (DSO) aktiviert werden. Konsultieren Sie bitte die Apache Dokumentation für weitere Informationen über Ihre Version. Hier ist eine sehr grundsätzliche Definition eines virtuellen Hosts. Diese Regeln leiten alle Anfragen auf index.php weiter, ausser wenn eine passende Datei im document_root gefunden wurde. ServerName my.domain.com DocumentRoot /path/to/server/root/my.domain.com/public RewriteEngine off RewriteEngine On RewriteCond %{REQUEST_FILENAME} -s [OR] RewriteCond %{REQUEST_FILENAME} -l [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^.*$ - [NC,L] RewriteRule ^.*$ /index.php [NC,L] ]]> Es ist der Schrägstrich ("/") zu beachten der index.php vorangestellt ist; die Regeln für .htaccess unterscheiden sich in diesem Punkt. Anbei ist eine einfache .htaccess Datei welche mod_rewrite verwendet. Das ist ähnlich der Konfiguration für virtuelle Hosts, ausser dass sie nur die Rewrite Regeln spezifiziert, und der führende Schrägstrich bei index.php nicht angegeben wird. Es gibt viele Wege um mod_rewrite zu konfigurieren; wenn man weitere Informationen haben will, dann sollte man in Jayson Minards Blueprint for PHP Applications: Bootstrapping sehen. Ab Version 7.0 wird IIS jetzt mit einer standardmäßigen Rewrite Engine ausgeliefert. Man kann die folgende Konfiguration verwenden, um die entsprechenden Rewrite Regeln zu erstellen. ]]>