Más contenido relacionado Similar a A textual DSL for UI Developement - Lessons from the Practice (20) A textual DSL for UI Developement - Lessons from the Practice4. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
Modellierung der UI-Komponenten einer Maske
• Textfelder, Checkboxen, Buttons, Tabellen etc.
• Einige Spezial-Komponenten, z.B. Widget für die Anzeige und Auswahl von Katalog-Einträgen
Databinding zum Businessobjekt-Modell
• Widgets werden mit Businessobjekt-Attributen verbunden
• Übernahme von Datentypen, Feldlängen aus dem Businessobjekt-Modell
• Swing-Komponente eines Widgets aus seinem Datentyp abgeleitet (Boolean Checkbox)
• Databinding auch zu berechneten Werten außerhalb des Businessobjekt-Modells möglich
Layout-Informationen
• Anordnung der Widgets in der Maske in textueller Syntax (kein graphischer Layout-Editor)
• Angabe von Layout-Constraints (für MiG Layout)
DSL mit Xtext, Generator mit Xpand
FormDSL – Die Idee
Eine DSL + Generator für Masken einer Swing-Anwendung
4
9. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
Bei Generator-Fehlern oder Feature-Wünschen kann die Reaktionszeit des DSL-Entwicklers
großzügiger ausfallen
• Fehlerbehebung oder Workaround durch den Masken-Entwickler in den generierten Base-Klassen
Manuelle Änderungen an generierten Base-Klassen können als Referenzimplementation für den
Generator dienen
Problematisch, wenn mehrere Masken-Entwickler an derselben Maske arbeiten, da manuelle
Änderungen versehentlich überschrieben werden können
Regelmäßige Kontrolle auf manuelle Änderungen, indem in einem Batch-Lauf alle Masken generiert
werden und die generierten Klassen mit dem Source Repository abgeglichen werden
• Verhindert, dass faule Masken-Entwickler ständig in den generierten Klassen herumschreiben
Bonus-Vorteil: Es muss nur das Eclipse-interne Build-System für das Generieren durch die Entwickler
funktionieren
• Kein zusätzliches Herumärgern mit einem Headless Build auf dem Build-Server
Lektion 1: Generierten Code kann man einchecken
Der Umweg über ein Source Repository bringt Vorteile
9
10. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
Wenige vollständig manuell programmierte Masken dienen als Referenzimplementation
Iteratives Aufbauen von DSL und Generator
• Frühzeitiges Verwenden der DSL für einfache Masken
• Nach und nach Umsetzen von komplexeren Masken, um fehlende Sprach-Features zu
identifizieren
• Erfahrungen der Masken-Entwickler mit der DSL und dem generierten Code können einbezogen
werden
Geschwindigkeit der Maskenentwicklung zunächst geringer
• Feedback zum DSL-Entwickler und fehlende Features kosten Zeit
• Die zunächst manuell programmierte Masken müssen anschließend mit der DSL erneut gebaut und
die bestehende Fachlogik übertragen werden
• DSL- und Generator-Entwicklung in dieser Phase Full-Time-Job, später nur noch Maintenance, d.h.
Fehlerbehebung und kaum noch neue Features
Lektion 2: Inkrementelles DSL-Design schafft Akzeptanz
Frühzeitiges Einbeziehen von Entwickler-Erfahrungen und -Wünschen
10
11. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
Generierter Code setzt auf der API eines zugrundeliegenden Frameworks auf
• Generator „kennt“ diese API und generiert Code gegen diese API
• DSL nutzt Konzepte der API oder abstrahiert von ihnen, z.B. „Widget“, „Button“ oder „Action“
Elegante Sprachkonstrukte der DSL nur möglich, wenn die Framework-API sie ermöglicht
• Anforderungen der DSL beim API-Design berücksichtigen
Hooks in der API der generierten Klassen anbieten, um manuelle Anpassungen vornehmen zu
können
• Überschreiben von preXxx()- und postXxx()-Methoden sowie createXxx()-Methoden
Übrige Wege verschließen (Methoden in Base-Klassen sind final)
• Entwickler bekommen nach Möglichkeit exakt einen Weg geboten, ihr Problem zu lösen
• Diese Weg soll der bequemste für die Entwickler sein und der eleganteste bzgl. der API und
Architektur
Lektion 3: Framework-API und DSL gemeinsam designen
Vorgaben und Anforderungen beider Teile beeinflussen einander
11
12. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
Diskrepanz zwischen der Ausdrucksmächtigkeit der DSL und der Komplexität von Masken und UI-
Komponenten
Es gibt zwei Wege, damit umzugehen:
1) Ausdrucksmächtigkeit der DSL erhöhen und damit die Komplexität der DSL erhöhen
2) Anknüpfungspunkte in Framework-API und generiertem Code schaffen, um exotische oder
komplizierte Anforderungen in der Ziel-Programmiersprache zu realisieren
Komplexe DSL ist von den Masken-Entwicklern schwerer zu erlernen und zu bedienen
Realisierungs- und Wartungsaufwand eines exotischen DSL-Features steht in schlechtem Verhältnis
zu seiner Nutzungs-Häufigkeit
Große Verlockung, Konzepte in die DSL aufzunehmen, die mit Databinding und Layout nichts zu tun
haben, z.B. Verhalten oder Navigation zwischen Masken
• Spezifische DSLs für diese Konzepte sinnvoller
• Modelle in verschiedenen DSLs können sich aufeinander beziehen
Lektion 4: Überfrachten der DSL ist verführerisch
Fokussieren der DSL auf ihre primäre Bestimmung
12
13. ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
© itemis AG
DSL wird von vielen Entwicklern über einen langen Zeitraum genutzt und trägt einen Großteil der Last
bei der Masken-Entwicklung
• DSL hat maßgeblichen Einfluss auf die Produktivität des Teams
• DSL hat das Experimental-Stadium des Xtext-Geeks verlassen
Es bestehen ähnliche Erwartungen an die Qualität wie für externe Werkzeuge
• Nicht-funktionale Features wie z.B. Gestaltung des Outline-Views, Editor-Icon, Formatter
• Referenz-Dokumentation und ggf. Schulungs-Material für neue Team-Mitglieder
• Saubere Plugin-Entwicklung z.B. Plugin-Namen und –Versionen
Höhere Turnaround-Zeiten für neue DSL-Features sind einzukalkulieren
Große Änderungen der DSL als „Zwischen-Projekte“ einplanen
• Nicht abwärtskompatible Änderungen erfordern u.U. das Anpassen hunderter Masken-Modelle
Lektion 5: DSL als professionelles Werkzeug ansehen
Professionelle Werkzeuge verlangen professionelle Pflege
13