START HERE FEATURE
Beyond Controllers
If one class owns the route, request parsing, validation, auth assumptions, business orchestration, and response assembly, it stops being simple and starts being the hidden coupling point of the whole feature.
Feature Guide
A quick orientation block that answers the essential questions: what this feature does, how it works, why it matters, and the key concepts behind it.
What this does
Understand why Semitexa keeps transport, use case, and rendering as separate explicit responsibilities.
Architecture Contrast
A controller is one object doing yesterday's whole HTTP stack
Semitexa is not anti-class. It is anti-collapse. The example payload below owns a real `{slug}` route parameter, its regex guard, normalization, and validation before the handler even starts business work.
The controller pattern feels compact only while the endpoint is trivial.
As soon as route parameters, input rules, auth rules, response variants, and SSR composition appear, the controller becomes a mixed-concern shell that is harder to test, harder to extend, and harder for tooling to explain.
| Concern | Typical controller-first class | Semitexa canonical owner |
|---|---|---|
| Route contract | Annotation or controller method metadata | Payload DTO |
| Input boundary | Request object + ad hoc reads | Payload setters and validation |
| Use case orchestration | Controller action body | Typed handler |
| Response shape | Inline arrays / Response building | Resource DTO |
| Extensibility | Middleware, helper traits, controller inheritance | Explicit contracts and modules |
Semitexa keeps the HTTP boundary typed so route discovery, validation, response decoration, and introspection can all reason about the same declared contract.
Verified against Semitexa Ultimate 2026.09.19.1020
Beyond Controllers
Semitexa does not treat controllers as the universal container for transport, orchestration, and rendering.
Canonical split
- payload owns inbound HTTP structure
- handler owns the use case
- resource owns response data and metadata
- template owns presentation
What this avoids
- transport and business logic collapsing into one unstable class
- hidden rendering state
- ad hoc arrays passed across unclear boundaries
Why this matters
The framework stays readable because each layer owns one job. That keeps growth additive instead of turning every new feature into another oversized controller.
Semitexa Canon
What to remember when building the first real feature
Once the transport boundary, use case, and response each have an owner, the rest of the framework becomes easier to inspect, extend, and automate.
Declare the route, HTTP methods, and payload boundary on the payload DTO, not in a controller method signature.
Keep the handler focused on orchestration and use-case flow, not transport parsing or response assembly details.
Let the resource own response shape, SEO metadata, and template context so rendering stays explicit and reusable.
Add modules and contracts around this typed spine instead of reopening one growing action class for every new concern.