Live demo

1 · Handler Shapes the response

The handler returns a typed Resource — every field the page can show, decided here.

2 · Resource = contract The page's shape, declared

You can read the whole page shape from the Resource class — product, related[] — without opening the template.

3 · Template Renders a prepared object

{{ product.name }} — the template references properties; it never queries or reshapes.

Typed Resource DTO Shape before render Inspectable response

Page Contract

In most "server-side rendering", the template is where the page actually takes shape. It pulls fields, calls helpers, reshapes collections and decides what is shown as it renders. The "contract" of the page is whatever the template happened to do — invisible until you read every line of it.

Semitexa inverts that. A handler returns a typed Resource — a response object whose public shape is the page contract. Every value the template can render is named and typed on the Resource before Twig runs. The renderer hands that prepared object to the template, and the template only ever references properties.

The shape is a thing you can read

Because the response is declared, the page becomes something you can reason about without rendering it:

Read it — open the Resource class and you know the entire page shape.
Test it — assert on the Resource in a unit test; no HTML, no DOM.
Change the look freely — rewrite the template with confidence, because the contract lives elsewhere.

This is the first pillar because every other one depends on the response being a declared thing, not an emergent one. The Presentation Boundary keeps it honest; Late and Live HTML extend it to regions; interactivity rides the same prepared-object model.

1#[AsPayloadHandler(payload: ProductPayload::class, resource: ProductResource::class)]2final class ProductHandler implements TypedHandlerInterface3{4    public function handle(ProductPayload $p, ProductResource $r): ProductResource5    {6        // The page's shape is decided HERE, before Twig runs:7        return $r->withProduct($this->repo->find($p->id()))8                 ->withRelated($this->repo->related($p->id()));9    }10}

#[AsPayloadHandler(payload: ProductPayload::class, resource: ProductResource::class)]
final class ProductHandler implements TypedHandlerInterface
{
    public function handle(ProductPayload $p, ProductResource $r): ProductResource
    {
        // The page's shape is decided HERE, before Twig runs:
        return $r->withProduct($this->repo->find($p->id()))
                 ->withRelated($this->repo->related($p->id()));
    }
}

1{# template renders a prepared object — it never queries #}2<h1>{{ product.name }}</h1>3<p>{{ related|length }} related items</p>

{# template renders a prepared object — it never queries #}
<h1>{{ product.name }}</h1>
<p>{{ related|length }} related items</p>

How it works

A handler returns a Resource — a typed response object whose public shape IS the page contract: every field the template can render is named and typed up front. The renderer hands that prepared object to Twig; the template references properties, never queries or services. You can read a page's entire shape by reading its Resource class, without opening the template.

Why it matters

When the response is explicit before render, the page becomes inspectable, testable and stable: assert on the Resource in a unit test, generate docs from it, and rewrite the template without fear because the contract lives elsewhere. It is the first pillar because every other one depends on the response being a declared thing, not an emergent one.