Shop Projekt - Dokumentation
Request-Flow (Laufzeit-Lebenszyklus)
Wie ein Request vom globalen HTTP-Einstiegspunkt bis zur finalen HTML-Ausgabe strukturiert durch das Projekt läuft.
Zielbild
Der Flow ist bewusst klar und linear aufgebaut: Einstieg, Initialisierung, Routing, Sicherheitsprüfung, Dispatcher und Ausgabe. So bleibt die Fachlogik von der Darstellung getrennt.
Ablauf im Hauptprojekt
- public/index.php definiert die Sicherheitskonstante SECURE_INCLUDE und lädt die app/bootstrap.php.
- cApp::run() startet sequenziell die Session, die Datenbankverbindung, den Router und den Access-Layer.
- cRouter::init() liest Sprache, Zielseite und die nav_UID aus der URL und spiegelt diese stabil in die Session.
- cSecurity::check_user_access() evaluiert die ACL-Rechte für die angeforderte Route, bevor Code ausgeführt wird.
- renderPage() lädt das Routing-Mapping aus app/control/map.php und führt die passende Controller-Action aus.
- Die rendernden Views lesen Labels und Kontexteigenschaften exklusiv aus cApp und cSession, niemals direkt aus superglobalen URL-Parametern.
Vereinfachte Reihenfolge
- SECURE_INCLUDE Schutz-Definition $\rightarrow$ public/index.php ruft app/bootstrap.php auf.
- cApp::run() initialisiert alle globalen Kernkomponenten (Session, DB, Router, ACL).
- renderPage() übernimmt den finalen Control-Dispatch in die zugeordnete Inhaltsroute.
Visualisierung der Schichten
Entwickler-Richtlinien (Worauf zu achten ist)
- Sprach- und Seitenkontexte gehören ausnahmslos in den Zuständigkeitsbereich des Routers, nicht in die View-Logik.
- Sicherheits- und Autorisierungsprüfungen müssen zwingend vor dem Start jeglicher Output-Generierung abgeschlossen sein.
- Existiert eine angeforderte Route im Mapping nicht, greift der vordefinierte Fallback auf den Home-Knoten.
- Der Dispatcher-Prozess dient reinen Orchestrierungsaufgaben und darf keine isolierte Business- oder Fachlogik abbilden.