# **Projektplan: Visueller AST-Editor**

* **Datum:** 02.09.2025 18:17

### **Motivation**

Der bestehende AST-Visualizer soll zu einem vollwertigen, interaktiven Editor ausgebaut werden. Ziel ist es, dem Benutzer die Erstellung und Bearbeitung von ASTs auf eine rein visuelle, intuitive und fehlerresistente Weise zu ermöglichen. Eine Kernanforderung ist die Möglichkeit, AST-Strukturen von externen Tools, insbesondere LLMs, über ein JSON-Format zu importieren.

### **Ziel**

Die Entwicklung eines robusten visuellen Editors, bei dem der Abstract Syntax Tree (AST) zu jeder Zeit in einem syntaktisch validen Zustand ist. Der Benutzer soll durch kontextsensitive Aktionen angeleitet werden, anstatt durch freies "Verkabeln" Fehler machen zu können. Das Design muss eine saubere Trennung zwischen der logischen AST-Struktur und ihrer visuellen Repräsentation gewährleisten, um die Anbindung an externe Tools zu vereinfachen.

### **Ergebnis: Architekturentwurf**

Der Editor basiert auf einem Model-View-Controller-Ansatz mit einer strikten Trennung der Verantwortlichkeiten.

**1\. Kernarchitektur: Der reine AST als Model**

* **Source of Truth**: Der IAstNode-Baum ist das alleinige Model und die "Source of Truth". Er enthält ausschließlich die logische Struktur und die Beziehungen der Knoten untereinander.  
* **Datenreinheit**: Das Model enthält keinerlei UI-spezifische Informationen wie Positionen, Farben, oder Zustände (z.B. "eingeklappt"). Diese Reinheit ist die Voraussetzung für eine einfache Serialisierung und die Interaktion mit externen Systemen.  
* **Mapping**: Eine zentrale Controller-Klasse verwaltet die Zuordnung zwischen Model und View, idealerweise über ein TDictionary\<IAstNode, TAuraNode\>.

**2\. Layout-Engine: Deterministische Visualisierung (View \= f(AST))**

* **Grundprinzip**: Die gesamte visuelle Darstellung wird bei jeder Änderung prozedural und deterministisch aus dem Zustand des AST-Models generiert.  
* **Layout-Algorithmus**: Der bestehende Ansatz aus dem TAstToAuraNodeVisitor wird formalisiert:  
  1. Für einen gegebenen Knoten werden zuerst rekursiv alle seine Input-Knoten (Kinder) von links nach rechts und oben nach unten positioniert.  
  2. Anschließend wird der Eltern-Knoten rechts von den Grenzen seiner Kinder platziert, typischerweise vertikal zentriert.  
* **Metadaten-Overrides**: Manuelle Änderungen am Layout durch den Benutzer (z.B. das Verschieben eines Knotens) werden als optionale Overrides behandelt. Diese werden in einer vom Model getrennten Struktur (TDictionary\<IAstNode, TUIMetadata\>) gespeichert. Beim Layout-Prozess wird für jeden Knoten zuerst geprüft, ob ein solcher Override existiert; falls nicht, wird die Position algorithmisch berechnet.

**3\. Editier-Paradigma: Socket-basierte, geführte Bearbeitung**

* **Ziel: "Always Valid AST"**: Jede vom Benutzer durchgeführte Aktion überführt den AST von einem validen Zustand in einen neuen validen Zustand. Syntaxfehler durch den Benutzer werden durch das Design ausgeschlossen.  
* **Sockets statt Palette**: Unverbundene Input-Pins dienen als "Sockets" und sind die primären Interaktionspunkte zum Erweitern des Baumes. Es gibt keine globale Palette, aus der beliebige Knoten auf eine leere Fläche gezogen werden können.  
* **Kontextsensitive Aktionen**: Ein Klick auf einen Socket öffnet ein Popup-Menü, das ausschließlich Aktionen und Knotentypen anbietet, die an dieser Stelle syntaktisch zulässig sind.  
* **Refactoring-Operationen**: Die Manipulation bestehender Knoten erfolgt durch gezielte Befehle wie "Ersetzen durch...", "Löschen" (setzt auf Socket zurück) oder "Umschließen mit...". Drag & Drop dient dem Umordnen von Sequenzen oder dem Verschieben ganzer, valider Teilbäume in einen kompatiblen Socket.

**4\. Serialisierung & LLM-Integration: Das duale Clipboard**

* **Zwei Anwendungsfälle**: Es wird zwischen der internen Benutzererfahrung und dem externen Datenaustausch unterschieden.  
* **Standard-Clipboard (Strg+C / Strg+V)**: Für die nahtlose Arbeit des Benutzers innerhalb des Editors.  
  * **Kopieren**: Serialisiert den ausgewählten AST-Teilbaum **inklusive** der UI-Metadaten (Layout-Overrides).  
  * **Einfügen**: Deserialisiert das Paket und reproduziert den visuellen Zustand 1:1.  
* **Logik-Clipboard (via Kontextmenü)**: Für den robusten Austausch mit LLMs und anderen Tools.  
  * **"Logik als JSON kopieren"**: Serialisiert den AST-Teilbaum **ohne** jegliche UI-Metadaten in ein pures, logisches JSON-Format.  
  * **"Logik aus JSON einfügen"**: Deserialisiert ein pures JSON. Eventuell vorhandene, fremde Metadaten werden tolerant ignoriert. Nach dem Einfügen wird der neue Teilbaum durch die Layout-Engine automatisch positioniert.

**5\. Undo/Redo: Das Command Pattern**

* Jede modifizierende Aktion (Knoten erstellen, verbinden, Eigenschaft ändern) wird als IEditorCommand-Objekt mit Execute- und Unexecute-Methoden implementiert. Ein Command-Manager verwaltet die Undo/Redo-Stacks.

### **TODO: Nächste Schritte**

1. **Architektur-Refactoring**:  
   * Entkopplung der IAstNode-Struktur von der TAuraNode-View.  
   * Einführung einer Controller-Klasse, die das Mapping (TDictionary) und die Interaktionslogik verwaltet.  
2. **Layout-Engine implementieren**:  
   * Formalisierung des deterministischen Layout-Algorithmus in einer wiederverwendbaren Einheit.  
   * Implementierung des Metadaten-Override-Systems.  
3. **Command Pattern implementieren**:  
   * Definition der IEditorCommand-Schnittstelle.  
   * Implementierung der grundlegenden Command-Klassen (CreateNode, DeleteNode, ConnectNodes, SetProperty).  
   * Aufbau eines TCommandManager für die Verwaltung der Undo/Redo-Historie.  
4. **Controller-Logik entwickeln**:  
   * Implementierung der Socket-Interaktion (Klick-Handler).  
   * Logik zur dynamischen Erzeugung der kontextsensitiven Menüs.  
   * Anbindung der Benutzeraktionen an das Command-System.  
5. **Duales Clipboard-System umsetzen**:  
   * Entwicklung der JSON-Serialisierungs- und Deserialisierungsroutinen für beide Formate (mit und ohne Metadaten).  
   * Implementierung der entsprechenden UI-Aktionen.