Dieses dreitägige Aufbauseminar richtet sich an Teams, die mit Eclipse Sprotty nicht nur schnelle Prototypen bauen, sondern eine tragfähige Editor-Architektur für den Dauerbetrieb aufsetzen wollen. Im Mittelpunkt stehen die internen Bausteine von Sprotty, die saubere Trennung von Modell, Rendering und Interaktion sowie die Frage, an welchen Stellen das Framework sinnvoll erweitert wird und an welchen Stellen man es besser in Ruhe lässt.
Zielgruppe
Das Seminar ist für Entwickler, Softwarearchitekten und Produktteams gedacht, die bestehende Diagramm- oder Modellierungswerkzeuge modernisieren, eigene Editoren entwickeln oder Sprotty als Frontend in eine größere Plattform einbetten wollen.
Voraussetzungen
Teilnehmer sollten sicher mit JavaScript oder TypeScript arbeiten können. Praktische Erfahrung mit SVG, Client-Server-Kommunikation und modularer Frontend-Entwicklung ist nützlich. Wer bereits ein erstes Sprotty-Projekt gesehen hat, kommt leichter hinein, zwingend ist das aber nicht.
Inhalte
- Kernarchitektur von Eclipse Sprotty und Zusammenspiel der wichtigsten Laufzeitkomponenten
- SModel, Zustandsübergänge und Datenfluss zwischen Modellquelle, Viewer und Rendering
- Dependency Injection mit InversifyJS und sauberer Modulaufbau für größere Projekte
- Action Dispatcher, Command Stack und Erweiterung von Aktionen und Befehlen
- Lokale und entfernte Model Sources, DiagramServerProxy und typische Integrationsmuster
- Eigene Modelltypen, eigene Views und registrierte Erweiterungspunkte
- Validierung, Nachverarbeitung und saubere Trennung von Fachlogik und UI-Logik
- Strategien für Debugging, Wartbarkeit, Testbarkeit und Performance unter Last
Praxisanteil
Die Teilnehmer erweitern ein Beispielprojekt Schritt für Schritt: neue Aktionen, zusätzliche Modelltypen, projektspezifische Regeln und eine nachvollziehbare Modulstruktur. Das Ergebnis ist kein Spielzeug, sondern ein belastbares Grundgerüst für eigene Sprotty-Projekte.
Nutzen im Projektalltag
Nach dem Seminar können Teams Sprotty-Erweiterungen geplant statt improvisiert umsetzen. Das spart bei späteren Anpassungen Zeit, verhindert wilde Sonderlösungen und schafft eine Architektur, die auch nach dem dritten Release noch lesbar bleibt.
