Request Flow
How a request moves from entry to output through the project.
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 SECURE_INCLUDE and loads app/bootstrap.php.
- cApp::run() starts session, database, router, and access layer.
- cRouter::init() reads language, page, and nav_UID from the URL and stores them in the session.
- cSecurity::check_user_access() validates access for the current route.
- renderPage() loads the route from app/control/map.php and executes the matching action.
- Views read labels and context from cApp and cSession, not directly from the URL.
Simplified order
- SECURE_INCLUDE is defined, then public/index.php loads app/bootstrap.php.
- cApp::run() initializes session, database, router, and access layer.
- renderPage() hands control to the matching route.
Flow overview
The same layer model also applies when the documentation later goes into detail.
What to watch
- Language and page are set in the router, not in the view.
- Access checks belong before output happens.
- If a route does not exist, a home fallback applies.
- The dispatcher should orchestrate only, not contain business logic.