Shop Project - Documentation

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

Array
Array

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.