RustAst/docs/FMX-Styles 1.md

📝 Projektplan: Refactoring der AST-Visualisierung (Architekturfokus)

Datum und Uhrzeit: 03.11.2025 09:02:21

💡 Motivation: Entkopplung und Skalierbarkeit

Die aktuelle Implementierung des AST Visualisierers in FireMonkey basiert auf einem Design mit starker Kopplung zwischen der semantischen Logik (Layout-Anordnung) und der visuellen Darstellung (Farben, Rahmen). Dies äußert sich in:

1. Visuelle Inflexibilität: Die TAuraNode.Paint-Methode verwendet Custom Drawing, was die zentrale Steuerung visueller Eigenschaften (z.B. für einen Dark Mode oder Branding) über FMX Style-Dateien unmöglich macht.
2. Architektonische Starrheit: Die Ableitung einer FMX-Control-Klasse (TAuraXxxNode) für jeden AST-Knotentyp ist ein Verstoß gegen das Open/Closed Principle und macht die Einführung neuer Knotentypen unnötig aufwendig.

Ziel des Refactorings ist die Trennung dieser Bedenken, um ein robustes, skalierbares System zu schaffen.

---

🏛️ Architektur: Strategisches Schichtenmodell

Die neue Architektur ersetzt die Vererbung durch Komposition und verteilt die Verantwortung auf drei Schichten:

1. FMX Style Aggregation (Visuelle Schicht)

Diese Schicht übernimmt die komplette visuelle Gestaltung des äußeren Rahmens.

• TAuraNode (Control Shell): Dient als generisches FMX-Control-Grundgerüst. Es erbt von TStyledControl und verwendet ein Style-Lookup basierend auf dem AST-Knotentyp (constantstyle, ifexpressionstyle, etc.).
• Visuelle Eigenschaften: Eigenschaften wie BackgroundColor, BorderWidth etc. sind nicht länger Felder in TAuraNode. Stattdessen werden sie über die FMX Style Accessoren (GetStyleProperty/SetStyleProperty) direkt in der geladenen FMX Style-Datei gespeichert und gelesen.
• Style-Bindung: Die ApplyStyle-Methode findet das primäre Style-Element (TRectangle mit StyleName='background') und wendet die Style-Eigenschaften (Farbe, Dicke, Radius) auf dieses Element an, wodurch das Custom Drawing in Paint obsolet wird.

---

2. Logik-Aggregation (INodeViewModel / Semantische Schicht)

Dieses Aggregat kapselt die gesamte Knoten-spezifische Logik (was einen if-Knoten von einem lambda-Knoten unterscheidet).

• INodeViewModel: Das zentrale Strategie-Interface. Es definiert die Schnittstellen Setup(HostNode, ...) zur Erstellung des Layouts und CreateAst(HostNode) zur Rekonstruktion des AST-Knotens aus dem visuellen Zustand.
• TNodeViewModelRegistry: Eine Factory-Klasse, die zur Laufzeit das korrekte INodeViewModel-Objekt (z.B. TIfExpressionViewModel) basierend auf dem TAstNodeKind des aktuellen Knotens instanziiert.
• TNodeViewModelBase: Bietet Helfer-Methoden (AddLabel, AddExpr mit Rekursion), die es der Setup-Methode ermöglichen, das semantische Layout (z.B. die vertikale Anordnung von "if", "then" und "else" Labels und Kind-Knoten) zu erstellen, ohne FMX-Interna zu duplizieren.

---

3. Ergebnis (Zusammenfassung)

Die Architektur trennt die statische visuelle Gestaltung (FMX Style) von der dynamischen Layout-Logik (INodeViewModel). Die generische Klasse TAuraNode wird zum Host, der die visuelle Schicht steuert und die Layout-Erstellung an die Logik-Schicht delegiert.