Live demo

Boundary leak Template loads data

{% set orders = repo.recentFor(user) %}
The template decides what the data is — business logic scatters, queries duplicate. Impossible in Semitexa.

Boundary kept Template renders prepared data

Handler: $resource->withOrders(...)
Template: {% for o in orders %} — it only renders. Data logic stays in one inspectable place.

No queries in templates Data shaped before Twig Structural boundary

Presentation Boundary

The presentation boundary is the line between deciding what the data is and deciding how it looks. Conventional templating quietly erases that line: templates query the database, call APIs, and invent view-side mapping rules. Once that happens, "how it looks" silently owns "what it is", and business logic scatters across files nobody thinks of as code.

Semitexa keeps the boundary structural. By the time Twig runs, all data is already shaped by the handler and the Resource. The render context is the Resource and nothing else — there is no repository, database handle or service reachable from a template.

A refusal, not a guideline

A template reaching into storage is treated as a structural failure, not a style preference. When a view needs a derived value, it is computed in the handler and named on the Resource — never improvised in Twig.

The payoff is that presentation can be rewritten freely while data logic stays in one inspectable place, and the same query never silently runs three times from three partials. This pillar is what keeps the Page Contract honest: the contract only means something if the template can't quietly route around it.

1{# ❌ Boundary leak — the template decides what the data is (impossible in Semitexa): #}2{% set orders = repository.findRecentFor(user.id) %}

{# ❌ Boundary leak — the template decides what the data is (impossible in Semitexa): #}
{% set orders = repository.findRecentFor(user.id) %}

1{# ✅ Boundary kept — the handler shapes, the template only renders: #}2//  handler:  return $resource->withOrders($this->orders->recentFor($user));3{% for order in orders %}4    <tr><td>{{ order.ref }}</td><td>{{ order.total }}</td></tr>5{% endfor %}

{# ✅ Boundary kept — the handler shapes, the template only renders: #}
//  handler:  return $resource->withOrders($this->orders->recentFor($user));
{% for order in orders %}
    <tr><td>{{ order.ref }}</td><td>{{ order.total }}</td></tr>
{% endfor %}

How it works

Handlers and Resource DTOs do the shaping; templates consume prepared values. There is no repository, DB handle or service reachable from a template — the render context is the Resource, nothing more. A derived value is computed in the handler and named on the Resource, never improvised in Twig.

Why it matters

A leaked boundary is where SSR rots: business logic scatters into templates, the same query runs three times, and "how it looks" silently owns "what it is". Keeping the boundary structural means presentation can be rewritten freely while data logic stays in one inspectable place. This is the pillar that keeps the Page Contract honest.