Verzeichnisstruktur
Dieser Artikel zeigt dir, in welchem Verzeichnis von n2n welche Komponenten abgelegt sind. Beachte, dass die Verzeichnisstruktur von n2n grundsätzlich flexibel ist. Das Ziel dieses Artikels ist, dass du weisst, in welchem Verzeichnis was abgelegt ist und du dich innerhalb der Struktur von n2n orientieren kannst.
Die Verzeichnisstruktur
In professionellen Projekten wird nicht auf dem produktiven Server entwickelt. Daher ist n2n für mehrere Umgebungen vorbereitet. Wir empfehlen dir, neben deiner produktiven Umgebung (Live-Server), mindestens eine Testumgebung zum Entwickeln anzulegen!
Für die Erstellung deiner Applikation sind folgende Verzeichnisse wichtig:
- app
- lib
- public
- var
Diese erläutern wir dir genauer.
Das /app Verzeichnis
Hier werden alle individuellen Module einer n2n Applikation gespeichert. Praktisch alle Arbeiten bei der Erstellung einer n2n Applikation finden in diesem Verzeichnis statt.
Das /lib Verzeichnis
Die Module, welche im Verzeichnis lib gespeichert werden, wurden unabhängig von deiner Applikation erstellt. Diese Module wurden generell für mehrere Applikationen programmiert. Damit diese Module laufend aktualisiert werden können, darfst du sie nicht anpassen! Wenn du im lib Verzeichnis Anpassungen machst, riskierst du, diese bei einem Update zu verlieren. Verbesserungswünsche an den Modulen im lib Verzeichnis müssen darum den Entwicklern der jeweiligen Module mitgeteilt werden. Generell kann darum festgestellt werden, dass du in diesem Verzeichnis bei der Programmierung deiner n2n Applikation nichts machen solltest.
Typische Module in diesem Verzeichnis sind:
- n2n: das n2n Framework
- rocket: das CMS Rocket, welches speziell für n2n entwickelt wurde
- util: verschiedene Tools, welche von rocket oder anderen Modulen verwendet werden
/vendor Verzeichnis kopiert. In diesem Falle kann es gut sein, dass dein /lib Verzeichnis leer ist.Das /public Verzeichnis
Im public Verzeichnis sind alle Dateien enthalten, welche dein Webserver direkt ausliefern soll. Eine produktive Umgebung sollte so eingerichtet werden, dass über den Webserver nur auf das public Verzeichnis zugegriffen werden kann. Alle anderen Verzeichnisse des Frameworks sollten nicht direkt erreichbar sein!
public Verzeichnis PHP Files zu speichern! PHP Files im public stellen ein unnötiges Sicherheitsrisiko dar. Die PHP Files, welche du für das Programmieren deiner App benötigst, speicherst du im app Verzeichnis.Ein PHP File, das im public-Verzeichnis stehen muss, ist das index.php. Die Einstellungen der .htaccess-Datei sorgen dafür, dass alle Pfade, für welche im public-Verzeichnis keine Datei oder kein Verzeichnis gefunden werden, an das index.php weitergegeben werden. Im index.php erstellt n2n einen ControllingPlan. Dieser sorgt dafür, dass alle Anfragen an die vorgesehenen Controller weitergeleitet werden.
index.php geprüft, ob Batch-Jobs fällig sind. Dies verlangsamt das System aber besonders bei aufwändigen Batchjobs. Um dies zu verhindern, kannst du den Aufruf der Batch Jobs in ein separates PHP File (z.B. batch.php) auslagern und dieses regelmässig über einen Cronjob aufrufen.Im public Verzeichnis gibt es zwei Unterordner:
- assets: hier werden die Files der Module gespeichert, auf welche die Besucher der Applikation aus dem Internet direkten Zugriff benötigen. Typischerweise sind dies Bilder, CSS- oder JavaScript-Files.
- files: hier werden Dateien gespeichert, welche mit Business Objects verknüpft sind und grundsätzlich von allen Besuchern abgerufen werden dürfen (Pulic File Manager). Dieses Verzeichnis wird von n2n automatisch erstellt, sobald erste Business Objects mit verknüpften Files existieren.
public Ordner gespeichert, weil sie so direkt vom Webserver ausgeliefert werden können und das Framework dafür nicht gestartet werden muss.Das /var Verzeichnis
Dies ist das Verzeichnis, wo Konfigurationen, Logs und Backups der Applikation gespeichert werden. Dieses Verzeichnis enthält beispielsweise folgende Unterverzeichnisse:
- bak: hier werden Backups gespeichert
- etc: hier werden die Applikation und die Module konfiguriert. Diese Daten sollten sich während der Laufzeit nicht ändern.
- log: hier werden die Logfiles abgelegt
- srv: hier kann deine Applikation Einstellungen und Daten zur Laufzeit speichern
- tmp: hier werden temporäre Dateien zwischengespeichert
Weitere mögliche Verzeichnisse
Wie bereits erwähnt, ist die Verzeichnisstruktur in n2n flexibel. Folgende weitere Verzeichnisse sind für n2n denkbar, aber nicht zwingend notwendig:
- build
- hangar
- test
- vendor
Build-Verzeichnis
Das build Verzeichnis ist für Publishing Skripte. Also die Skripte, welche dein Projekt von der Testumgebung aus aufbereiten (z.B. CSS- und JS-Minimierung) und alle benötigten Komponenten auf eine andere Umgebung (z.B. Produktion) spielen.
Der Hangar
Der Hangar unterstützt dich bei der Erstellung und Konfiguration deiner n2n Applikation und ist typischerweise im hangar Verzeichnis abgelegt. Er nimmt dir viele repetitive Arbeiten ab. Hangar ist separat dokumentiert.
Test-Verzeichnis
/test ist das Verzeichnis für sämtliche Test-Scripte.
Vendor
Wenn du n2n über den Composer installierst, erstellt der Composer ein /vendor Verzeichnis. Darin sind alle Module abgelegt, welche über Composer geladen werden.
/vendor Verzeichnis in seiner Funktion dem /lib Verzeichnis ähnlich. Module die über den Composer geladen werden, solltest du in der Regel nicht verändern oder anpassen. Du wirst darum kaum je etwas in /vendor anpassen müssen.