Tag Archives: Technologie

DSL Tutorial Teil 2


Flattr this

Um was geht es?

Dies ist der letzte Teil meines 2 teiligen DSL Tutorials. Ziel des Tutorials ist das Erstellen einer DSL zur Beschreibung von Vektorgrafiken und der Bereistellung eines Generators um daraus svg Dateien zu erzeugen. Die DSL wird in [DSL-1] erstellt. Dieser 2. Teil befasst sich aufbauend auf Teil 1 mit der Erstellung eines Generators.

Einrichten der Arbeitsumgebung

Vor Beginn dieses Teils müssen Sie alles unter [DSL-1] beschriebene durcharbeiten. Ich setze die funktionierende DSL mit der im Teil 1 vorgenommenen Definition voraus.

Los gehts

Die folgend dargestellten Projekte sollten im Eclipse Arbeitsbereich zu sehen sein.

015 ProjektUebersicht

Als Erstes fügen wir dem DSL Projekt die Acceleo Nature hinzu und aktualisieren die Ansicht.

016 AddNature

Nun weisst unser DSL Projekt ein Overlay Icon von Acceleo auf und wir können über das Kontextmenü das Generatorprojekt erzeugen.

017 GeneratorProjektErzeugen

Es erscheint ein geführter Dialog per Wizard. Hier passen wir den Projektnamen so an, dass er statt auf ui auf generator endet. Außerdem nehmen wir Änderungen an den Settings (letzte Tab) vor. Die nachfolgenden Bilder verdeutlichen dies.

018 Dialog 019 Einstellungen

Wichtig der Filter der Dateinamen! Er entscheidet darüber für welche Dateien der Generator zur Verfügung stehen wird. Außerdem habe ich mich für einen eigenen Target Pfad entschieden (target/generated-sources), damit nicht ausversehen Projektdateien überschrieben werden.

Zum Abschluss bitte mit Finish bestätigen.

Im neuen Projekt setzen wir als Erstes den Java Output Build Pfad auf target/classes, da ohne diesen Schritte manchmal keine Templates angelegt werden können. Nun müssen wir auch dem neuen Generator Projekt zunächst manuell die Acceleo Nature zuweisen (leider nimmt Acceleo diese Zuweisung nicht automatisch vor). Nun stehen auch hier weitere Kontextmenüeinträge zur Verfügung. Somit können wir nun im Package org.emftext.language.svgd.generator ein Main Template anlegen. Dazu bitte auf dem Package Ordner über das Kontextmenü den Neu Dialog aufrufen und Acceleo Main Module File auswählen. Dann einfach Next und Finish – der Rest ist bereits korrekt vorbelegt.

020 MainTemplateAnlegen

Jetzt sind 2 neue Dateien im Package entstanden: eine Main.java (interessiert uns nicht weiter) und eine main.mtl. Letztere sollte auch geöffnet wurden sein und wird von uns nun mit folgendem Inhalt gefüllt:

[comment encoding = UTF-8 /][module main(‚http://www.emftext.org/language/svgd‘)/][template public main(model : SVGModel)][comment @main /][for (element : Form | model.elements)] [file (element.name.concat(‚.java‘), false, ‚UTF-8‘)] Testfile [/file][/for][/template]

Im common Package in der Klasse GenerateAll ersetzen wir die doGenerateMethode mit folgendem Code:

Code der doGenerate Methode in GenerateAll.java

Wenn wir unsere DSL jetzt wieder als Eclipse Anwendung starten, können wir dort zu unserem Beispiel bereits Code generieren. Achtung die verschiedenen Formen sollten auch verschiedene Namen bekommen damit nicht alle die gleiche Java Klasse generieren 🙂

021 BeispielInstanz

So sieht ein erstes Beispiel aus. Damit ist der Generator prinzipiell arbeitsfähig und wir können uns dem Implementieren der Fachlichkeit zuwenden.

Den vollständigen Umfang der Acceleo Sprache zu erklären möchte ich hier gar nicht erst versuchen (dazu gibt es eine sehr schöne Hilfe in Eclipse selber). Aber damit das Tutorial am Ende auch eine SVG Datei generiert, habe ich folgende Änderung an der main.mtl durchgeführt. Bitte den Inhalt der Datei komplett ersetzen mit dieser main.mtl (odt) oder dieser main.mtl (doc) .

Leider lies sich der Code hier im Blog nur schlecht formatieren. Auf jeden Fall muss die <?xml Zeile ganz links anfangen da sonst der Browser das Bild nicht interpretieren kann. Und so kann ein funktionierendes Beispiel in Eclipse aussehen.

022 FinalesBeispiel

Ich hoffe das Tutorial konnte einen Einblick in die Praxis des Generatorbaus geben. Ziel war den Leser schrittweise zu einem funktionierenden Beispiel zu verhelfen. Der Aufwand zur Erstellung des Tutorials hat dann doch mehr als ein Wochenende in Anspruch genommen. Daher habe ich auch auf die Erklärung vieler Details verzichtet.

Falls jemand weitere Fragen dazu hat oder Details wissen möchte, bitte kommentieren dann liefere ich diese noch nach.

Vielen Dank fürs Lesen und viel Spass beim Generieren 🙂

[DSL-1]

DSL Tutorial Teil 1

RIAs und ihre Unterschiede


Flattr this
Am Wochenende habe ich mir [Bosch2010] zu Rich Clients durchgelesen. Dieser Artikel hat mich motiviert eine kleine Bestandsaufnahme zum Thema RIA zu verfassen.

Definition

RIA steht für Rich Internet Application. Und bereits hier wird es problematisch, da es keine einheitliche Definition darüber gibt, was unter einer solchen verstanden wird.  Ein guter Einstieg ist wie immer Wikipedia. Was bleibt ist eine Begriffsvielfalt an Wortschöpfungen: Thin Client, Rich Client, Fat Client, Rich Thin Client … Die Historie zu diesem Thema wird sehr gut in [Mueller2009] beschrieben. Im Ergebnis dieser Lektüre bin ich zu dem Schluss gekommen, dass man sich mit seinem Gegenüber (im aktuellen Fall mit dem Leser) vorher über die Definition einigen sollte. Ich persönlich bevorzuge die Definitionen wie sie in [Mueller2008] Verwendung finden.

Danach ist Fat alles was Business Logik auf dem Client implementiert. Hierzu werden auch einfache Validierungen gezählt die sich nicht über reguläre Ausdrücke beschreiben lassen. In [Mueller2008] werden Rich Clients generell in 2 Architekturtypen unterteilt:

  • Generischer Rich Client der  Thin Ansatz
    Gemeint ist ein Client welcher nur das Rendering übernimmt. Früher bei Mainframes waren das mal die Terminals, später war es der Browser. Wichtiges Merkmal: Der Zustand wird vom Server verwaltet.
  • Implementierter Rich Client der Fat Ansatz. Hierunter zählen die früher so typischen Client-Server Systeme. Der Client beinhaltet die gesamte Business Logik und die Daten liegen auf dem Server. Nachteil: Die Business Methoden müssen zusätzlich geschützt werden, da viele Clients direkt darauf zugreifen.

In [Bosch2010] kommt der Autor zu der Erkenntnis, dass sich die Technologien von Webanwendungen und Rich Clients kaum noch unterscheiden und daher eine Unterscheidung über feingranularere Kriterien notwendig wird. Bislang wollte ich dieser Argumentation nicht folgen, da Rich Clients für mich spezielle Webanwendungen darstellten. Unter Beachtung der Aussagen aus [Mueller2008] – als Rich Clients zählen auch typische Client-Server Systeme der 90’er – schließe ich mich nun doch der Meinung des Autors an.

Ausgewählte Frameworks und RIA Technologien

Inzwischen existieren unzählige Frameworks und Technologien zum Thema Rich Client. Hier ist eine kleine aber hoffentlich bekannte Auswahl:

Merkmale der RIA Architekturen

Die einzelnen Kriterien stammen aus [Bosch2010]. Sollten sich in Zukunft weitere ergeben, werde ich diese hier einfügen.

Laufzeitumgebung

Jede RIA Technologie benötigt eine bestimmte Laufzeitumgebung. Hierbei kann man unterscheiden ob diese standardmäßig dem Endbenutzer zur Verfügung steht oder erst installiert werden muß. Ein Browser ist in aller Regel auf Endbenutzer PCs verfügbar. Damit wäre also die Laufzeitumgebung für HTML 5 sofort verfügbar. Andere wie Adobe*AIR, Adobe Flash Player oder Java müssen zunächst installiert werden.

Manche Laufzeitumgebungen lassen sich erweitern. So ist die Java VM über das JNI API generell erweiterbar. Das nutzt beispielsweise Eclipse RCP und muss im Gegenzug auf den Einsatz als Applet verzichten, da Applets eine solche Erweiterung nicht erlaubt ist.

Verteilung

Die einzelnen Technologien lassen sich  auch gut über die Programmverteilung  an den Endbenutzer unterscheiden. So gibt es Technologien wie Webstart die direkt im Browser laufen und bei Bedarf durch 1-Click-Installationen permanent auf dem Client PC bereitgestellt werden können. Andere Technologien müssen vor ihrem Einsatz generell erst installiert werden.

Oberflächen Technologie

Hier gibt es Technologien, welche das Rendering einzelner Oberflächen Elemente direkt auf UI Komponenten des Betriebssystems abbilden – beispielsweise SWT. Andere Technologien versuchen nur wenn absolut notwendig die Oberflächen Elemente auf UI Komponenten des Betriebssystems abzubilden, beispielsweise JavaFX und Adobe AIR. Die Elemente welche nicht über das Betriebssystem gerendert werden, sind von der Laufzeitumgebung selbst zu rendern.

Deklarative Oberflächendefinition

Moderne Technolgien ermöglichen eine deklarative Beschreibung der Oberflächen, beispielsweise JavaFX, GUI4J, Thinlet*classic u.s.w. Eine deklarative Oberflächenbeschreibung bringt den Vorteil, dass sich die Oberfläche deutlich schneller beschreiben und daraus erste Prototypen entwickeln lassen. Auch die Erstellung von Design Werkzeugen wird dadurch erleichtert.

Binding

Als Binding bezeichnet der Autor in [Bosch2010] das Binden von Oberflächen Elementen an ein separates Modell welches den Zustand und das Verhalten der Oberfläche repräsentiert. Er verweist dabei auf das Presentation Model Pattern. Dies scheint etwas anders zu funktionieren als das klassische Model-View-Controler Pattern. Auch bei den Thinlet*classic und GUI4J wurde bereits ein Binding verwendet.

Animationen

Moderne Client Oberflächen verfügen teilweise über eingebettete Animationen. Diese werden durch Sprachen wie JavaFX und Flex bereits unterstützt. Auch diese Unterstützung kann als Kriterium benutzt werden. Zukünftig wird wohl die Art der Unterstützung mehr in den Vordergrund treten. Außerdem erwarte ich hier noch weitere Kriterien auf Grund der Tatatsache, dass sich die Anwendungen immer mehr auf die Verwendung von Hypermedien stützen (Video, Audio, …).

Weitere Merkmale der RIA Architekturen

Hier folgen Kriterien welche ich persönlich noch für wichtig halte, die aber nicht in [Bosch2010] ausgewertet wurden.

Protokoll

Ein wesentlicher Teil einer RIA Architektur bilden die Protokolle welche zur Kommunikation zwischen Client und Server verwendet werden. Von ihrem Entwurf hängt es wesentlich ab wann und wie oft ein Roundtripp zum Server notwendig wird. So verwendet Canoo beispielsweise das Half Object plus Protocol (HOPP) Pattern.

Quellen

[Schenkel2006] Schenkel, Thorsten: Teile und Herrsche – Smart Clients Teil 3 In: Java Magazin , Nr. 10 (2006) .

[Mueller2008] Müller, Björn: Wie rich darf’s denn sein? In: Java Magazin , Vol. 12 (2008) , S. 38 – 42 .

[Mueller2009] Müller, Florian: Kolumne: Tour de GUI In: Java Magazin , Vol. 7 (2009) , S. 46 .

[Bosch2010] Bosch, Tobias: Rich Clients – In oder out? In: Java Spektrum , Nr. 6 (2010) .