Refactor WebAppAdapter::start() and ConsoleAppAdapter::start() into structured runtime pipelines
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start with src/App/Adapters/WebAppAdapter.php and src/App/Adapters/ConsoleAppAdapter.php, then trace the related traits and src/App/BootPipeline.php. Compare the current start() flows with RouteDispatcher.php and MiddlewareManager.php to map the runtime state and responsibilities. Done means both adapters use dedicated runtime pipelines and context objects while preserving the listed web and console behavior; update tests as needed.
Written by the indexing model from the issue text.
Description
Summary
Refactor WebAppAdapter::start() and ConsoleAppAdapter::start() so runtime execution is no longer handled as flat sequences of loosely connected method calls.
Introduce structured runtime pipelines for web and console flows, similar in spirit to boot stages, so execution becomes explicit, extensible, and ready for future lifecycle hooks.
Why
The constructor already has a clear staged boot flow through BootPipeline, but runtime execution is still handled ad hoc.
In WebAppAdapter::start(), current responsibilities are mixed together in one method:
- preflight handling
- route resolution
- not found handling
- language loading
- debug info logging
- view cache setup
- cached response lookup
- route dispatch
- middleware execution
- response sending
- request cleanup
In ConsoleAppAdapter::start(), runtime execution is also flat:
- core command registration
- app command registration
- command validation
- command execution
This makes both runtime flows harder to reason about and leaves no clean structural boundaries for future lifecycle hooks.
Goal
Create proper runtime execution structures for both web and console adapters before introducing broader lifecycle hooks.
Runtime flow should become stage-based rather than remaining collections of ad hoc method calls.
Proposed Direction
Introduce dedicated runtime pipelines instead of reusing BootPipeline directly.
Suggested runtime structures:
RequestPipelineRequestContextConsolePipelineConsoleContext
These should carry evolving runtime state rather than relying on loose locals and inline control flow.
Suggested Web Runtime Stages
A reasonable first breakdown of the current web flow is:
HandlePreflightStageResolveRouteStageHandleRouteNotFoundStagePrepareRequestStageDispatchRequestStageSendResponseStageCleanupRequestStage
Notes:
PrepareRequestStageshould cover:- language loading
- debug info logging
- view cache setup
DispatchRequestStageshould cover:- cached response lookup
- route dispatch
- middleware execution
Suggested Console Runtime Stages
A reasonable first breakdown of the current console flow is:
RegisterCoreCommandsStageRegisterAppCommandsStageValidateCommandStageRunCommandStage
If needed, command registration can later be collapsed into a single preparation stage, but the first refactor should prioritize clarity.
Scope
This ticket is about refactoring runtime structure for both adapters.
It should not yet define the full lifecycle hook contract. That should come after runtime flow has proper structural boundaries.
Acceptance Criteria
WebAppAdapter::start()is refactored into a structured runtime pipelineConsoleAppAdapter::start()is refactored into a structured runtime pipeline- runtime state is carried through dedicated runtime context objects rather than loose local variables
- web runtime responsibilities such as language loading and view cache handling are preserved in the new structure
- console runtime responsibilities such as command registration, validation, and execution are preserved in the new structure
- the new runtime structures are suitable for later lifecycle hook integration
- tests are updated as needed
Notes
Relevant code:
src/App/Adapters/WebAppAdapter.phpsrc/App/Adapters/ConsoleAppAdapter.phpsrc/App/Traits/WebAppTrait.phpsrc/App/Traits/ConsoleAppTrait.phpsrc/Router/RouteDispatcher.phpsrc/Middleware/MiddlewareManager.phpsrc/App/BootPipeline.php
This ticket should be completed before introducing broader runtime lifecycle hooks.
- Dominant language
- PHP
- Stars
- 36
- Forks
- 22
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from quantum-php/framework
-
routing testing
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
quantum-php/framework#547 ·
-
view
Difficulty 1/5 Under an hour Newbie friendliness 75/100
quantum-php/framework#542 ·
-
enhancement http
Difficulty 5/5 Over a week Newbie friendliness 35/100
quantum-php/framework#565 · 1 comment ·
-
components view
Difficulty 5/5 Over a week Newbie friendliness 42/100
quantum-php/framework#551 ·
-
Add explicit @version special route token support for API major versioning within a single module Openrouting
Difficulty 5/5 Over a week Newbie friendliness 45/100
quantum-php/framework#550 ·
All issues in quantum-php/framework
Similar issues
-
status/awaiting_triage
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
WordPress/plugin-check#1486 ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
az-digital/az_quickstart#6019 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
grokability/snipe-it#19688 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100