feat: closure-based view system

[gharlan]

Introduces a typed, statically analysable view layer in src/View, alongside the existing Fragment system (which is left untouched — no fragments are converted in this PR). It is a first version; details may still change before the 6.0 release.

Motivation

The current Fragment system passes an untyped var-bag into a template that runs in a $this scope (registered as a PHPStan/Psalm universal object crate), so nothing about a fragment's inputs is statically checked — call sites don't know which vars exist, which are required or what types they have, templates need @var/@psalm-scope-this boilerplate, and the optional escape flag is opaque to taint analysis.

What's in here

• Html — typed safe-HTML value object, itself a Renderable. Html::from() escapes a plain string / renders any Renderable; Html::raw() wraps trusted markup; Html::capture() captures a closure's output so callers can write real inline HTML. The escaping decision lives in the type, not a runtime flag.
• Renderable / RendersView / HasView — a class renders a co-located ClassName.view.php: a file that returns a typed, inert static closure receiving the whole object. render(): Html, no $this/scope-this magic, fully type-checked, runtime-enforced.
• Renderer — internal engine that requires the view file and invokes the closure inside an output buffer (cleaned up on throw).
• ViewResolver — identity-based override: a project or addon can replace any class's view by FQCN (ViewResolver::override(Foo::class, $file)), last registration wins.

Content properties take Renderable, so sub-components can be passed directly without calling ->render(). "Slots" are covered by typed optional Renderable properties + named arguments (no dedicated slot runtime). The project starter's DefaultTemplate ships a co-located DefaultTemplate.view.php as the intended authoring pattern.

Example

A component is a small typed class plus a co-located view file (illustrative — this PR ships the base; a real use is the project starter's DefaultTemplate):

Badge.php — the constructor is the statically-checked contract:

namespace Redaxo\Core\View\Component;

use Redaxo\Core\View\Renderable;
use Redaxo\Core\View\RendersView;

final class Badge implements Renderable
{
    use RendersView;

    public function __construct(
        public string $label,
        public string $type = 'default',
    ) {}
}

Badge.view.php — co-located (same base name), returns a typed closure that receives the object:

<?php

use Redaxo\Core\View\Component\Badge;

use function Redaxo\Core\View\escape;

return static function (Badge $badge): void { ?>
    <span class="label label-<?= escape($badge->type) ?>">
        <?= escape($badge->label) ?>
    </span>
<?php };

Call site — typed, named arguments, no var-bag:

echo new Badge(label: 'New', type: 'info')->render();

$badge->label/$badge->type are fully analysed in the view, and escape() keeps output safe. Since render() returns Html (which is Renderable), a Badge can also be passed straight into another component's content property — no manual ->render():

echo new Panel(title: 'Status', body: new Badge(label: 'New', type: 'info'))->render();

Deliberately out of scope (follow-ups)

• Converting the existing fragments (tracked separately on claude/view-system-fragments; will likely be restructured conceptually rather than translated 1:1).
• An HtmlAttributes helper for attribute handling in views.
• A slot runtime for partial view overrides, multi-view modules (input/output), and override auto-discovery — only if a real need shows up.

Verification

Green under phpunit, php-cs-fixer, phpstan (level 6) and psalm/taint. Covered by tests in tests/View (Html, Renderer, RendersView, ViewResolver, slot pattern).

🤖 Generated with Claude Code

[staabm]

might be worth doing the inverse. escape everything per default and add a helper function to work with a raw value.

that way you get XSS protection by default