Der Request-Lebenszyklus #

Diese Seite richtet sich an Entwickler, die wissen möchten, wo ihr Code bei einem Web-Request ausgeführt wird, so wie sie die HttpKernel-Ereignisse von Symfony, die Middleware-Pipeline von Laravel oder den Request- und Response-Zyklus von Django kennen. Die maßgebliche Beschreibung ist Der Request-Lebenszyklus in der Kernel-Architektur; diese Seite geht ihn mit den Augen eines Framework-Entwicklers durch.

Inhalt #

1. Die Schritte
2. Dieselben Schritte als Pipeline
3. Wo Sie sich einklinken können
4. Unter persistenten Workern
5. Requests auf der Kommandozeile

Die Schritte #

1. index.php. Wenn var/maintenance.json existiert, kann expMaintenance::check() antworten (Wartungsmodus). Ein Request mit exp_repair wird an ezpRepairQueue übergeben. Danach lädt autoload.php den Autoloader von Composer und die erzeugten Klassenzuordnungen, config.env.php und config.php werden gelesen, und $kernel = new ezpKernel( new ezpKernelWeb() ); echo $kernel->run()->getContent(); führt den Request aus.
2. Aufbau des Kernels. ezpKernelWeb liest i18n.ini und site.ini, aktiviert die globalen Erweiterungen, ermittelt den Siteaccess mit eZSiteAccess::match() anhand von Request-URI und Host, wechselt mit eZSiteAccess::change() zu ihm, aktiviert die Erweiterungen des Siteaccess und lädt die Einstellungen neu, damit die Siteaccess-Ebene greift (Siteaccesses).
3. Initialisierung von Sitzung und Request (sessionInit(), requestInit()), danach die Ereignisse request/preinput und request/input. Die CSRF-Prüfung von ezformtoken ist ein Listener auf request/input.
4. URL-Übersetzung. Ein URL-Alias (/About-us) wird über eZURLAliasML zu einer Systemadresse (content/view/full/58); URL-Platzhalter werden über eZURLWildcard angewendet (Sprechende URLs).
5. Modulsuche und Zugriffsprüfungen. Das Modul muss in einem Modul-Repository existieren und erlaubt sein (eZModule::accessAllowed()); die Anmeldeprüfung des Siteaccess (Richtlinie user/login) und die Richtlinienfunktionen der View (eZUser::hasAccessToView()) laufen vor der View. Request-Regeln entscheiden nach der Alias-Übersetzung und nachdem die Richtlinien die View erlaubt haben (Middleware: Request-Regeln).
6. Die View läuft. $module->run( $functionName, $params, ... ) führt das View-Skript oder die Klasse ModuleView aus, die ein $Result-Array zurückgibt. Eine View kann einen erneuten Durchlauf mit einer anderen URI oder eine Weiterleitung anfordern (eZModule::STATUS_RERUN, STATUS_REDIRECT); die Dispatch-Schleife behandelt beides (Controller).
7. Seitenlayout und Ausgabe. Der content des Ergebnisses wird in das pagelayout.tpl des Siteaccess eingesetzt (sofern die View kein anderes oder gar keines gewählt hat), durch die Ausgabefilter response/preoutput und response/output geleitet und zurückgegeben. ezformtoken fügt in einem Listener auf response/output sein verstecktes Token in Formulare ein.
8. Abschluss. Ausstehende Daten werden geschrieben; unter Velocity setzt der Worker seinen Zustand für den nächsten Request zurück.

Dieselben Schritte als Pipeline #

Wo Sie sich einklinken können #

Unter persistenten Workern #

Unter Velocity wird die Anwendung einmal in einem Elternprozess geladen und in Worker geforkt, die jeweils viele Requests bedienen. Die Schritte 2 bis 8 laufen pro Request, aber alles, was eine Klasse in einer statischen Eigenschaft hält, überlebt bis in den nächsten Request, sofern es nicht zurückgesetzt wird. Die Regeln des Kernels: kein Request-bezogener Zustand in statischen Eigenschaften ohne Zurücksetzen, kein exit zur Ablaufsteuerung außer über eZExecution::cleanExit(), und eine geänderte Klasse oder Einstellung erreicht die Worker erst nach ./console exp:velocity restart oder exp:velocity deploy (Server: Velocity, PHP-FPM und FrankenPHP). Wenn Sie Laravel Octane oder Symfony auf RoadRunner kennen: Es gilt dieselbe Disziplin.

Requests auf der Kommandozeile #

Konsolenbefehle, Cronjob-Teile und Queue-Worker verwenden ezpKernelWeb nicht. Sie starten über eZScript, das die Einstellungen für den mit -s angegebenen Siteaccess lädt, und laufen als anonymer Benutzer, sofern der Code keinen Benutzer anmeldet (Kommandozeile).

Verwandte Seiten #

• Architektur für Anwendungsentwickler
• Das Front-Controller-Muster
• Velocity: der Server mit persistenten Workern
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.