Booking Monitor Supportforum

Nach einigen (vielen) Überlegungen und Recherchen habe ich mich dazu entschlossen Zend Framework zu verwenden. Ausgerechnet Zend Framework, weil es die meisten notwendigen Funktionalitäten bietet, auf die ich Zugreifen werde.

Zu Anfang werden Klassen, die mit I18N, L10N, Translate, Date, DB arbeiten, genutzt. Außerdem wird die Grundstruktur einer Zend Applikation eingesetzt mit Zend Controller und Zend Fehlerbehandlung. Es wird jedoch auf Zend View Scripte verzichtet. Stattdessen wird Smarty verwendet.

Da der Booking Monitor aus mehreren Modulen bestehen soll, werden alle Controller in mehrere Unterverzeichnisse eingeteilt, die in “application/modules/” liegen. Alle Bibliotheken liegen im Ordner “library”. Dazu zählt im Moment Smaty, Zend und BM (Booking Monitor). Das einzige über Webbrowser aufrufbare Script ist “index.php” im Wurzelverzeichnis (/booking-monitor). Ich konnte index.php nicht in einem Unterordner platzieren, weil das Script auf verschiedenen Systemen einsetzbar sein soll. Auch dort, wo der Webspace-Inhaber keinen Zugriff auf übergeordnete Verzeichnisse (außer public) hat. Die Nennung “kundendomain.de/public/index.php” soll damit vermieden werden.

Das System soll sowohl im Rootverzeichnis eines Domainnamens, als auch in einem Unterverzeichnis einsatzfähig sein. Entwicklung findet in dem Ordner “/booking-monitor” auf “devel.booking-monitor.com” statt. Im Ordner “/project”, das auf dem Bild zu sehen ist liegen Dateien, die nicht öffentlich sind und haben nur intern mit Entwicklung zu tun. Dort speichere ich Diagramentwürfe, Texte (die ich in diesem Forum schreibe) und sonstige Dateien.

Alle Ordner, die über Webbrowser nicht aufrufbar sein sollen beinhalten eine “.htaccess” Datei mit “deny from all” Anweisung. Das soll die unbefugten Zugriffe verhindern.
Im Verzeichnis “data” soll der User, die Unterordner mit 0777 Rechten erstellen. Alle Ordner dort sollen beschreibbar sein. Im Prozess der Entwicklung kommen sicherlich noch ein paar Ordner dazu.

Order “sme” steht für “simple module export”. Über dieses Modul sollen später Objekt- und Buchungsbezogene Daten (geplant als JSON) aufrufbar sein. Dies wird eine Schnittstelle sein, über welche der Anwender den Booking Monitor in eigene Webpräsenz integrieren wird.

Das ist bereits zweite Architektur. Die erste Architektur habe ich vor ca. einem bis anderthalb Monaten entworfen. Die Architektur nutzte kein Zend Framework. Dann, nach vielen Überlegungen, habe ich mich dazu entschlossen das ZF einzusetzen. Die Wahl fiel auf ZF aus mehreren Gründen: mächtige Unterstützung (Google, Microsoft etc.), breite Klassenpalette, logische und verständliche Architektur, Pluginfähigkeit, zukunftsversprechend, lizenzfreundlich etc.