... | ... | @@ -4,10 +4,16 @@ Dabei kratze ich nur an der Oberfläche des Frameworks selbst. Für eine genaue |
|
|
|
|
|
Dies soll einen generellen Überblick über die Struktur geben und erhebt keinen Anspruch auf eine vollständige Beschreibung aller ablaufenden Prozesse:
|
|
|
|
|
|
### Eingang des HTTP-Requests
|
|
|
### Eingang des HTTP-Requests `/public/index.php`
|
|
|
Beim Aufruf von z.B. [https://metager.de/meta/meta.ger3?focus=web&eingabe=test&encoding=utf8&lang=all](https://metager.de/meta/meta.ger3?focus=web&eingabe=test&encoding=utf8&lang=all) geht die Anfrage auf Grund der .htaccess Datei im Verzeichnis `/public/` bei `/public/index.php` ein.
|
|
|
Zunächst werden hier der User-Agent und die IP-Adresse des Abfragenden anonymisiert, damit auch wir später keinen Zugriff mehr darauf haben.
|
|
|
Als nächstes werden alle benötigten Klassen vom `Laravel-Classloader` geladen, damit dies später nicht mehr passieren muss.
|
|
|
Nun müssen noch die Abhängigkeiten aufgelöst und die Einstellungen geladen werden. Dieser Prozess instanziert das Objekt `App`.
|
|
|
|
|
|
### Verarbeitung des aufgerufenen Pfades `/app/http/routes.php`
|
|
|
An dieser Stelle werden die übergebenen Pfade verarbeitet und entschieden auf welche Art die Anfrage beantwortet werden soll.
|
|
|
Dabei gibt es etliche Möglichkeiten, z.B.:
|
|
|
1. Kann direkt ein View zurückgegeben werden
|
|
|
2. Kann die Funktion eines Controllers aufgerufen werden, welcher widerum am Ende einen View zurück gibt. Alle Controller befinden sich dabei unter `/app/Http/Controllers`
|
|
|
3. Kann zusätzlich eine Middleware definiert werden, also ein Programm welches ausgeführt werden soll nachdem die Anfrage angenommen wurde, aber bevor diese verarbeitet wird.
|
|
|
3. |