Shop Project - Documentation

language

Request Flow (Runtime Lifecycle)

How a request moves from the global HTTP entry point to the final HTML output through the project.

🗺️ Stage 1 | 📚 Draft | 📟 2026 06 15 | 📍 Core System

Goal

The flow is intentionally linear: entry, initialization, routing, access checks, dispatcher, and output. This keeps business logic separate from rendering.

Main Project Flow

  • public/index.php defines the security constant SECURE_INCLUDE and loads app/bootstrap.php.
  • cApp::run() sequentially starts session, database connection, router, and access layer.
  • cRouter::init() reads language, target page, and nav_UID from the URL and stores them stably in the session.
  • cSecurity::check_user_access() validates ACL permissions for the requested route before any code execution.
  • renderPage() loads the route mapping from app/control/map.php and executes the matching controller action.
  • The rendering views read labels and context properties exclusively from cApp and cSession, never directly from superglobal URL parameters.

Simplified Order

  • SECURE_INCLUDE definition $\rightarrow$ public/index.php loads app/bootstrap.php.
  • cApp::run() initializes all global core components (Session, DB, Router, ACL).
  • renderPage() handles the final control dispatch into the mapped content route.

Layer Visualization

Request flow through the application layers
The layer logic strictly separates the HTTP entry point from app initialization and the view.

Developer Guidelines (What to watch out for)

  • Language and page contexts belong exclusively to the router domain, never inside view logic.
  • Security and authorization checks must absolutely finish before any output generation begins.
  • If a requested route does not exist in the mapping, the predefined fallback to the home node triggers.
  • The dispatcher process serves orchestration purposes only and must not contain isolated business logic.