Michael Korte – Senior Full-Stack Developer Freelancer aus Dortmund

Ziel dieses Teils

Bis hierhin haben wir:

  • einen klaren Request-Lifecycle
  • Routing als Entscheidung
  • Controller als Orchestratoren
  • PageContext als Seitenzustand

Was noch fehlt, ist der letzte Schritt: HTML-Ausgabe.

Wichtig

Ab hier gilt eine harte Regel: Nur der Renderer erzeugt Output.

6.1 Warum Rendering ausgelagert wird

In klassischen MVC-Setups passiert Rendering oft:

  • direkt im Controller
  • implizit durch Framework-Magie
  • verteilt über Helper, Traits und globale Funktionen

Das führt zu einem Problem:

Typischer Effekt

Niemand kann später sicher sagen, wo HTML entsteht und warum.

Clean-Output-MVC zieht hier eine klare Grenze.

6.2 Rolle des Renderers

Der Renderer ist die einzige Instanz, die:

  • PageContext kennt
  • Templates kennt
  • Asset-Renderer kennt
  • HTML erzeugt

Er ist keine Business-Logik, sondern eine Orchestrierungs-Schicht.

6.3 Minimaler Renderer (konzeptionell)

<?php
namespace Core;

final class Renderer
{
    public function render(PageContext $page): string
    {
        // Status-Code setzen
        http_response_code($page->getStatus());

        // Assets vorbereiten (CSS / JS)
        $this->renderAssets($page);

        // Template rendern
        return $this->view->render(
            $page->getTemplate(),
            $page->getData()
        );
    }
}

Details wie Asset-Gruppierung, Hooks oder Blocks kommen später – das Prinzip bleibt gleich.

6.4 Zusammenspiel: Controller → Renderer

Wichtig ist, was nicht passiert:

  • Controller rufen keinen Renderer
  • Controller kennen keine Templates
  • Controller geben keinen String zurück

Stattdessen:

  • Controller liefern PageContext
  • App übergibt PageContext an Renderer
  • Renderer erzeugt HTML

6.5 Warum das wichtig ist

Technisch

  • klarer Output-Punkt
  • kein doppeltes Rendering
  • vorhersehbare Fehlerseiten

Konzeptionell

  • HTML als Produkt
  • Architektur bleibt erklärbar
  • Hooks & Checks zentral möglich

Zwischenstand

An diesem Punkt steht ein vollständiges, aber bewusst minimalistisches System:

  • Index → Bootstrap → App
  • Middleware (vorbereitet)
  • Router → Controller
  • PageContext
  • Renderer → HTML

Wichtig

Das System ist absichtlich noch unbequem. Komfort kommt nach Struktur.

Was als Nächstes kommt (bald)

  • Teil 7 – Templates & Layouts (Twig)
  • Teil 8 – Assets (CSS & JS sauber einbinden)
  • Teil 9 – Block-System (strukturierte Inhalte)
  • Teil 10 – Fehlerseiten & Statuscodes
  • Teil 11 – Ausblick: Erweiterbarkeit & CMS-Perspektive
← zurück