Differences

This shows you the differences between two versions of the page.

--- scriptlog:architecture:overview [2026/09/28 01:41] – admin admin
+++ scriptlog:architecture:overview [2026/09/28 02:01] (current) – admin admin
@@ Line 47: / Line 47: @@
 The order matters, because each step depends on the previous one having
 finished. Read it as a strict pipeline, top to bottom — the diagram first,
-then the nine numbered steps underneath it (DokuWiki has no numbered-list
+then the nine numbered steps underneath it (this wiki has no numbered-list
 syntax, so the steps carry explicit numbers):
@@ Line 72: / Line 72: @@
 ===== 3. Wiring =====
-`Bootstrap` is a static factory made of many small private methods. The order of
+`Bootstrap` is a static factory made of many small private methods. `initialize()` runs four stages: `loadConfiguration()`, the `utility-loader.php` require, `initializeServices()`, then `applySecurity()` (which ends in `initializePostSecurity()`). The service graph inside `initializeServices()` runs top to bottom:
-its own methods is the service graph:
-  * `loadConfiguration()`, `initializeServices()`, `createDatabaseConnection()`
+^ Order ^ Methods ^
-  * `initializeRegistry()`, `createBaseDaos()`, `createSession()`
+| 1 | `createDatabaseConnection()`, `defineRoutingRules()`, `initializeRegistry()` |
-  * `createAuthenticator()`, `createThemeRenderer()`, `createFrontService()`
+| 2 | `createBaseDaos()`, `createSession()`, `createAuthenticator()` |
-  * `createDownloadChain()`, `createContentDaos()`, `storeInRegistry()`
+| 3 | `createThemeRenderer()`, `createDownloadChain()`, `createContentDaos()` |
-  * `createDispatcher()`, `buildServiceMap()`, `buildHandlerRegistry()`
+| 4 | `storeInRegistry()`, `createFrontService()`, `createDispatcher()` |
-  * `initializeI18n()`, `applySecurity()`, `initializePostSecurity()`
+| 5 | `buildServiceMap()`, `buildHandlerRegistry()`, `buildAdminActionRegistry()` |
+| 6 | `initializeI18n()` |
-Everything is then published into the global `Registry` via `Registry::setAll()`,
+**Ordering constraint:** `createFrontService()` resolves its DAOs from the `Registry` at construction time, so it must run *after* `storeInRegistry()`.
-and the service map is bound into a service locator. Controllers reach their
-collaborators through that locator rather than through constructors, which is
+The graph is composed with plain `new` calls, so each object's collaborators are visible in its constructor signature. Shared instances are additionally published into the global `Registry` (`Registry::setAll()` in `initializeRegistry()`, plus `Registry::set('frontService', ...)` afterwards) for late binding from theme helpers, `HandleRequest` and `front_service()`.
-why the dependency graph is hard to read from the controller class alone.
 ===== 4. Request lifecycle =====
-Once `Dispatcher::dispatch()` runs, the shape of the response depends on one
+Once `Dispatcher::dispatch()` runs, one configuration value decides the shape of the response: `rewrite_status`.
-configuration value, `rewrite_status`:
-  * `'yes'` — SEO-friendly URLs. `handleSeoFriendlyUrl()` resolves an optional locale prefix first, strips it, and matches the remainder against the route table.
+^ `rewrite_status` ^ Handler ^ Behavior ^
-  * anything else — `handleQueryStringUrl()` serves the classic `?pg=`, `?p=`, `?a=`, `?cat=`, `?tag=`, `?search=`, `?q=` form.
+| `'yes'` | `handleSeoFriendlyUrl()` | Resolves an optional locale prefix first, strips it, then matches the remainder against the route table. |
+| anything else | `handleQueryStringUrl()` | Serves the classic `?pg=`, `?p=`, `?a=`, `?cat=`, `?tag=`, `?search=`, `?q=` form through `HandleRequest::deliverQueryString()`. |
-The `?download=` case is handled **before** the SEO branch as well, so a
+The `?download=` case is handled first at the top of the SEO branch as well, so a
 download keeps working regardless of the permalink setting.
-A matched route is then validated by a `validate*()` method
+Every matched route then flows through one pipeline:
-(`validateContentExists`, `validateSinglePost`, `validatePage`,
-`validateCategory`, `validateArchive`, `validateTag`), the matching theme
+<code>
-handler is looked up, and the response is produced by `invokeTheme()`.
+route match --> validate*() --> handler lookup
-`renderTheme()` serves a full page; `renderHtmxFragment()` serves a partial for
+  --> invokeTheme() --> renderTheme() | renderHtmxFragment()
-HTMX requests. Frontend routes are compiled once into `$frontendCompiled`.
+</code>
+Validation is one `validate*()` method per page type (`validateContentExists`, `validateSinglePost`, `validatePage`, `validateCategory`, `validateArchive`, `validateTag`). `renderTheme()` serves a full page; `renderHtmxFragment()` serves a partial for HTMX requests. Frontend routes are compiled once into `$frontendCompiled`.
 ===== 5. The route table =====