Verzeichnisstruktur

Diverses

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.

  1. Die Verzeichnisstruktur
  2. Das /app Verzeichnis
  3. Das /lib Verzeichnis
  4. Das /public Verzeichnis
  5. Das /var Verzeichnis
  6. Weitere mögliche Verzeichnisse

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
Achtung, wenn du n2n über Composer installiert hast, dann werden die Module n2n, rocket und page ins /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!

Es macht in den meisten Fällen keinen Sinn, im 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.

In der Standard Einstellung wird im 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.
JPG, PNG, GIF, JS und CSS werden im 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.

Hangar ist ein von n2n unabhängiges Tool, welches nicht als Open Source veröffentlicht wird. Hangar darf jetzt und in aller Zukunft kostenlos verwendet werden, du hast aber nicht das Recht, Anpassungen zu machen und diese weiterzuverbreiten. 

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.

Grundsätzlich ist das /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.
« Inside n2n Modul erstellen »

comments_title

post_login_to_create

questions_title