Invisible Docs
GalerieTokens

Invisible Framework

Ein UI-Framework für alles, was tricoma zeigt

Websites, Onlineshops, Webanwendungen — aus einer zentral definierten, versionierten Bibliothek, über Design-Tokens umgestaltbar. Diese Doku ist selbst ein Konsument: gebaut komplett aus Framework-Bausteinen, ohne eigenes CSS.

Die zwei TürenUI-Kit-Galerie
anwendung.php
// Tür 1: das Framework als Bibliothek
echo invisible_render_id('component.table', [
    'columns' => $spalten,
    'rows'    => $zeilen,
]);

Was ist Invisible?

Ein versioniertes, deklaratives UI-System: Oberflächen werden nicht programmiert, sondern als validierbare Strukturen beschrieben und von einem Produktionsrenderer in HTML übersetzt.

Das Wichtigste zuerst: eine Bibliothek für alles

Die Schichten bilden zusammen eine pflegbare, standardisierte Bibliothek — und diese eine Bibliothek ist die Basis für alles, was auf ihr entsteht: den kommenden tricoma Desktop, Website-Templates, Shop-Templates, E-Mail-Marketing-Templates und Web-Apps. Ein Button wird EINMAL gebaut, gepflegt und versioniert — und erscheint überall; ein Theme-Wechsel oder ein Token-Update wirkt in jedem Kanal gleichzeitig. Es gibt keine Desktop-Buttons, Shop-Buttons und Mail-Buttons mehr, die auseinanderlaufen.

Das System beantwortet drei Probleme klassischer UI-Entwicklung gleichzeitig:

  • Doppelte Wahrheiten: Jeder Baustein hat genau ein Manifest. Registry, Assets, Builder-Controls und Doku werden daraus generiert — nichts wird zweimal gepflegt.
  • Unkontrollierbares Kunden-HTML: Kunden wählen Props und Design-Tokens — nie freie Klassen, nie CSS, nie JavaScript. Kunden-JSON ist grundsätzlich untrusted und kann das System nicht beschädigen.
  • Kaputte Seiten nach Updates: Publizierte Seiten sind unveränderlich (immutable Versionen). Breaking Changes an Bausteinen liefern Migrationen mit — alte Seiten rendern weiter, bis sie beim nächsten Publish automatisch migriert werden.

Die zwei Türen

PHP-Bibliothek für Anwendungen, Surface-JSON für redaktionelle Seiten — dieselben Definitionen.

Kapitel lesen

Das Ebenen-Modell

Foundations → Layouts → Elements → Components → Blocks → Templates — jede Ebene zeigt nur nach unten.

Kapitel lesen

Das Raster

Zwölf Spalten, die Breite steht am Kind — niemand baut sein eigenes Raster.

Kapitel lesen

Design-Tokens

Drei Ebenen: Referenz, Semantik, Komponente — Themes kippen das gesamte Erscheinungsbild.

Kapitel lesen

Der Kerngedanke in einem Satz

Woraus besteht das System?

BausteinAufgabe
Definitionen definitions/Der Katalog: Tokens, Layouts, Elements, Components, Blocks, Templates, Actions — je ein Ordner mit Manifest, Props-Schema, Renderer, CSS, Demo
Build build/Kompiliert Tokens → CSS-Variablen, validiert alle Manifeste, erzeugt Registry-Cache und gehashte Assets (@apply aufgelöst)
Kernel + Renderer kernel/, renderers/Render-Vertrag, Props-Validierung, Surface-Renderer (JSON → HTML), Publish-Gates, Migrationen
Runtime runtime/Interaktivität im Browser: Lifecycle, semantische Events, Action-Dispatcher, Services (Navigation, Window, Notification)
Produkt-Werkzeuge archiv/Builder, Site-Vorlagen, Publish- und Katalog-Verwaltung sind Werkzeuge des CMS-Produkts auf dem Framework — seit 2026-08-10 archiviert (→ Framework vs. Konsumenten)

Weiter mit Die zwei Türen — oder direkt ins Ebenen-Modell.