Category Archives: Technologie

XII. Captain Casa Community Meeting


Flattr this

Motivation

Seit ich vor 8 Jahren im Java Magazin einen Artikel von Björn Müller gelesen hatte, interessiere ich mich für das Captain Casa Framework. Die Captain Casa GmbH führt seit Ihrer Gründung 2007 jährlich ein Community Meeting durch. Auf diesem treffen sich Nutzer und Lizenznehmer der Captain Casa GmbH, sowie Partner als auch generell Rich Client Interessierte. Zu Letzteren zähle ich mich und so nutze ich hin und wieder die Möglichkeit am Treffen teilzunehmen. 2016 bot sich für mich zur Teilnahme an, da bereits in der Vorankündigung große Dinge, in Worten „RISC HTML“ ihre glänzenden Strahlen vorausschickten. 

Organisation

Die Treffen an denen ich persönlich teilgenommen habe fanden bislang stets in Eppelheim statt. Dieses Jahr wurde ich durch eine Einladung nach Schwetzingen überrascht. Für mich als Besitzer einer Bahn Card ist Schwetzingen von Nürnberg her besonders günstig zu erreichen. Mein Hotel buchte ich keine 5 Gehminuten vom Bahnhof Schwetzingen entfernt. Der Veranstaltungsort (ein modernes Gemeindehaus) lag ebenfalls nur wenige Gehminuten sowohl vom Bahnhof wie auch vom Hotel entfernt. Da der Zeitpunkt des Treffens in der beginnenden Vorweihnachtszeit lag, konnte ich am Vorabend noch über den Weihnachtsmarkt schlendern und in aller Ruhe ein Souvenir für zu Hause auswählen. Für eine Schlossbesichtigung reichte die Zeit meines Aufenthalts leider nicht aus aber dieses Vorhaben wird in Zukunft nachgeholt. 

Teilnehmer

Wie auch schon in der Vergangenheit kamen vorwiegend proffessionelle Nutzer des Captain Casa Frameworks. Neu für mich war ein scheinbar gewachsener Anteil englischsprachiger Nutzer für die eine Simultanübersetzung angeboten wurde. Weiterhin hatte das Treffen auch Rich Client Interessierte Freiberufler angelockt, welche offensichtlich in Projekten in denen das Captain Casa Framework eingesetzt wird unterwegs sind. 

Stimmung

Auch an der Stimmung hat sich im Laufe der Zeit nichts geändert. Es war wieder eine sehr harmonische Stimmung unter den Teilnehmern. Viele kannten sich bereits durch vorangegangene Treffen und tauschten rege Ihre Erfahrungen über das Framework aus. Alle äußerten sich positiv zum Einsatz des Frameworks und lobten den hervorragenden Support der Captain Casa GmbH.

Inhalt der Veranstaltung

Generell lässt sich der Inhalt in folgende Bereiche einordnen:

  • Rückblick auf das letzte Treffen mit aktueller Markt- und Trendanalyse
  • Erfahrungsberichte von Unternehmen bzw. Captain Casa Nutzern.
  • Vorstellung technologischer Neuerungen durch die Captain Casa GmbH.
  • Ausblick und Roadmap über die weitere Entwicklung des Frameworks
  • Blick über den Tellerrand – ein Gastvortrag zur Architekturdokumentation

Markt- und Trendanalyse

Dass sich in der Vergangenheit bei der Entwicklung von Webanwendungen große Veränderungen ihren Weg bahnten und zu einer neuen Ära in der Sparte führten musste nicht erwähnt werden. Daher begann das Meeting auch gleich mit der Positionierung und Einordnung des Captain Casa Frameworks in den bestehenden Markt. Das wiederum ist aus meiner Sicht ein wirklich sehr wichtiger Punkt. Die Captain Casa GmbH, welche mit ihrem Framework bislang Swing, JavaFX und HTML Clients unterstützte, ist nicht ausgezogen um sich mit Giganten wie AngularJS etc. zu messen, sondern verfolgt ihren bewährten Weg weiter.

Das Captain Casa Framework ist für den Bau von Anwendungen erdacht, welche durch Power User genutzt werden. Natürlich nutzt auch ein Entwickler ein Office oder ein Mailprogramm aber sein Powerprogramm ist die IDE. Andere Anwender wie Dispatcher oder Anlagenfahrer benötigen evtl. auch Office oder Mailprogramme oder ähnliche Software aber auch sie haben ein Powerprogramm in welchem sie ihre Hauptarbeitsgänge erledigen. Möglicherweise werden Schaubilder mit Maschinen erstellt, mit Datenquellen hinterlegt und in einen Ablauf gebracht. Vielleicht müssen auch Güter verwaltet oder gelagert werden oder oder oder. Auf jeden Fall wird es etwas geben was der Nutzer zu Beginn seines Arbeitstages als Programm startet um damit möglichst viele seiner Tätigkeiten durchführen zu können. Genau für den Bau solcher Programme ist das Captain Casa Framework erdacht worden und genau hier spielt es seine Stärken aus. Wer allerdings einfach ein Portal seiner Firma ins Internet setzen möchte, dem genügen Technologien von Google und Co. Da muss nicht noch ein neues Framework geschaffen oder ein Bestehendes umgebaut werden. 

RISC HTML – die neue Technologie

Offensichtlich gab es nach dem letzten Community Meeting eine Phase welche Björn Müller inspirierte die bestehende HTML Technologie des Captain Casa Frameworks zu optimieren. Der Vorteil einer HTML GUI ist im Prinzip die Zero Installation. HTML benötigt einen Browser und der ist beim Endnutzer in der Regel verfügbar. Leider gibt es dabei aber auch einen Nachteil, es gibt nicht nur einen Browser. Was im IE läuft sieht im Chrome schon ganz anders aus und ist im Mozilla evtl. gar nicht mehr sichtbar oder anders herum. Damit sich der Entwickler letztlich nicht mit diesen Dingen rumschlagen muss gibt es genau solche Frameworks wie das Captain Casa Framework. Diese sorgen mit Magie einfach dafür, dass es in jedem Browser gleich aussieht und auch gleichartig funktioniert. Die neue Magie des Frameworks heißt nun also RISC HTML. 

Was genau aber ist nun RISC HTML? Hinsichtlich der Erfahrungen welche vor Jahren bereits im Hardwarebereich gesammelt wurden, nämlich der Umstieg von CISC auf RISC Technologie wurde auch das Framework überarbeitet. Genau wie beim Prozessor wird auch beim HTML eigentlich nur ein kleiner Satz von Elementen benötigt um eine ganze Anwendung aufzubauen. So könnten evtl. Rechtecke und Texte vollkommen ausreichen um das Layout einer Seite zu berechnen. Wir erinnern uns dabei natürlich sofort an das Prinzip des Textsatzsystems Latex zurück. Hier wird alles was darzustellen ist als Rechteck beschrieben und relativ zu einem umgebenden Rechteck positioniert. Mit einem DIV Tag und einer absoluten Positionierung im CSS Style wäre so etwas auch im HTML möglich. Der Legende nach war dies der erste Versuch im Werdegang von RISC HTML, die Darstellung von 20000 absolut positionierten DIVs im Browser. Voila es funktioniert – nun gut das hätte auch jeder erwartet dafür sind Browser ja gebaut worden. Jetzt noch die Zeit gemessen und mit einer Referenzimplementierung in Swing und JavaFX verglichen und uuuupps ist das schnell. So in etwa stelle ich mir die Geburtsstunde von RISC HTML vor. 

In weiteren Versuchen stellte sich dann wohl heraus, dass diese Methode tragfähig ist und etwa mit 4 Grundelementen auskommt. Aber wer genau setzt sich jetzt hin und schreibt die absoluten Positionierungen an die HTML Elemente? Nein natürlich nicht der Entwickler, das erledigt der Layoutmanager. Diesen kennen wir bislang nur aus der Swing und JavaFX Ecke und so fragen wir uns wie genau dieser denn jetzt ins Spiel kommt. Ganz einfach: Layoutmanager ist Logik und Logik auf HTML Seiten wird in JavaScript realisiert. 

Der Vorteil dieser Technologie liegt auf der Hand. Es gibt einen Kernel welcher für das Rendering und Verhalten der (4) definierten Grundelemente Sorge trägt. Also dafür sorgt, dass diese von jedem Browser gleichartig verarbeitet werden. Darauf aufbauend gibt es eine Schicht in welcher diese Grundelemente solange kombiniert und aggregiert werden, bis eine Vielzahl neuer Komponenten daraus entstanden ist. In dieser Schicht lassen sich dann auch eigene Komponenten erstellen. 

One Pass Rendering

Kennen Sie diesen Effekt wenn Sie auf einem leistungsschwachen Tablet eine herausfordernd überfrachtete Webseite modernster Bauart ansteuern und gerade einen schmalen Button klicken wollen, doch noch in der Bewegung ihres Fingers wird die Seite neu layoutet und der Button ist jetzt woanders und sie drücken dadurch an gleicher Stelle nun auf einen Link der eine Seite lädt die sie gar nicht sehen wollen und welche sich noch langsamer aufbaut als die vorherige? Dieser Effekt liegt am layouting Mechanismus der Browser. Größe und Position der dargestellten Elemente ist erst bekannt wenn diese auch dargestellt werden. 

Bei RISC HTML ist das anders. Hier kennt jedes der Elemente seine Größe vorher durch die absolute Positionierung und dem Layoutmanager. Ändert sich die Größe eines Elements wird ein dirty Event an das umgebende Element gesendet. Dieses meldet ebenfalls dirty und so weiter. Es entsteht ein kurzzeitiger Event Sturm nach oben bis zum äußersten Element. Dieses sammelt in aller Ruhe alle Events ein und wartet dabei bis auch die letzte dirty Meldung eingetroffen ist. Erst jetzt sendet es ein render Event zurück und alle Elemente berechnen ihre Position im umgebenen Element neu. Da die Berechnung von außen nach innen erfolgt ist die Position des äußeren Elements stets bekannt und fest. Damit kann es nicht zu dem anfangs beschriebenen Verhalten kommen.

Page Bean Components

Von vielen in der Community scheinbar unbemerkt, haben die Page Bean Components ihren Weg in das Captain Casa Framework gefunden. Page Bean Components bieten dem Entwickler die Möglichkeit das Framework um eigene Komponenten zu bereichern und als eigenständige Deliverables in Form von JARs auszuliefern/auszutauschen. Ganz klar ein Punkt Richtung Community – hier kann sich jeder zum Komponenten Provider herauf schwingen und damit nicht nur für sich selbst sondern auch für andere Entwickler hilfreiche Dinge zur Nachnutzung erstellen. Die genaue Erstellung solcher Komponenten würde den Rahmen dieses Artikels sprengen, wird aber vorgemerkt als zukünftig eigener Artikel auf meinem Blog. 

Ausblick

Zukünftig möchte die Captain Casa GmbH das Framework vorwiegend im Bereich RISC HTML weiter entwickeln. Die Swing und JavaFX Clients verbleiben im Wartungsmodus bis die Community keine weitere Unterstützung wünscht. Diese Priorisierung soll sich zukünftig auch im Lizenzkostenmodell widerspiegeln. Änderungen an den Open Source Lizenzbedingungen (Binary License) sind mir auf dem Treffen nicht bekannt geworden, dennoch sollten diese vor einer Realisierung selbstverständlich gelesen und für das jeweilige Vorhaben geprüft werden. 

Am Rande des Tellers

~ bleibt immer noch Luft für weitere Dinge. Zum Beispiel für eine schöne automatisierte Architekturdokumentation. Der Gastredner Falk Sippach nutzte im Rahmen eines aufgelockerten Vortrages die Vorteile von Dokumentation an den Teilnehmer zu bringen. Hier merkte man sofort die praktischen Erfahrungen auf dem Gebiet und es baute sich die Hoffnung auf nun doch noch endlich alles dokumentieren zu können ohne Redundanzen und ohne Wenn und Aber. Der Redner kannte sich aus mit den üblichen Fallstricken und benannte Lösungen. So geht der Trend eindeutig in Richtung plain text basierter Dokumentation. Natürlich documentation as a code also im Versionskontrollsystem hinterlegt, idealerweise gleich beim Code (genau wie bei den fachlichen Stories von BDD).  Zielgruppen gerechte Dokumente generiert im üblichen Build Prozess. Die verfügbare Palette an Werkzeugen scheint schier grenzenlos und wartet nur auf ihre Entdeckung. Allein die Kombination der Werkzeuge zur gut geölten Werkzeugkette scheint das Salz in der Suppe zu sein. Hier muss wohl jeder für sich entscheiden welche Werkzeuge er warum und in welcher Reihenfolge einsetzt. Einige mir nützlich erscheinende Buzzwords möchte ich dennoch unkommentiert fallen lassen: asciidoc, asciidoctor, markdown, yed, plantuml, ditaa, graphiz, jQAssistant. 

Schlußwort

Aus meiner Sicht war es wieder ein sehr schönes und interessantes Community Treffen. Die Captain Casa GmbH hat einmal mehr gezeigt, dass sie ein steter Quell sowohl nachhaltiger als auch revolutionärer Ideen ist. Zusammenfassend hat sich bei mir der Eindruck gefestigt, dass es sich beim Captain Casa Enterprise Client auch weiterhin um ein sehr gutes, solides und fantastisches Framework handelt.

Hinweise und Kommentare zum Artikel sind wie immer ausdrücklich erwünscht.

DSL Projekt aufsetzen (mit Xtext)


Flattr this

Motivation

Da es ein wenig Mühe bereitet hat und ich nach einem Jahr nicht noch einmal den Aufwand investieren möchte schreibe ich hier eine kleine Anleitung wie man ein DSL Projekt unter folgenden Randbedingungen aufsetzt:

  • Als Entwicklungsumgebung wird eclipse eingesetzt
  • Zur Sicherstellung einer einheitlichen eclipse Installation wird yatta-profiles genutzt
  • Zur Modellierung der DSL wird Xtext verwendet
  • Die Sourcen werden auf github.com gehostet
  • Als CI System kommt travis-ci.org zum Einsatz
  • Zur Verteilung der Releasestände wird bintray.com genutzt

Die Eclipse aufsetzen

Lange habe ich nach einer Möglichkeit gesucht um diesen Schritt zu automatisieren. Angefangen über das Niederschreiben der Installation hier im Blog (Eclipse konfigurierenEclipse aufsetzen) über CloudConnect bin ich letztlich auf Yatta-Profiles gekommen. Yatta Profiles hat sich für meine Arbeitsweise als am besten geeignet erwiesen um die zu installierenden Plugins und die aus zu checkenden Projekte einheitlich für ein Team zu verteilen (Allerdings nutze ich das Angebot nicht als Team sondern als einzelner Entwickler. Halte mir aber die Möglichkeit offen mit mehreren Leuten zu gleich an einem Projekt zu entwickeln.)

Bleibt das Speichern der eigentlichen Konfiguration der installierten Plugins. Diese Arbeit kann ich an das Oomph Plugin delegieren. Zum Glück hat das Projekt jetzt eine Reife erlangt die zur produktiven Arbeit genügen sollte. 

Wer meine Eclipse Installation ausprobieren möchte, kann sich einfach das Yatta-Profile installieren: ECLIPSE XTEXT DSL TOOLS

Die Sourcen erstellen

Generell beginne ich mit dem Anlegen eines leeren Repositories (Projekt) auf Github. Dabei wähle ich zunächst den Namen aus, dann gebe ich java als Programmiersprache an und wähle eine mir genehme Lizenz aus. Weiterhin selektiere und aktiviere ich die Checkbox „Readme erstellen“. Nach dem Fertigstellen bietet github.com ein neues Projekt zum clonen an und genau das mache ich dann auch – ich klone das Projekt mittels git clone <url> in ein lokales Verzeichnis auf meinem PC. 

Nun starte ich eclipse und erzeuge über den Dialog „Neu/Projekt/Xtext“ ein neues xtext Projekt.

Hierbei sind bereits ein paar wichtige Dinge zu beachten. Da ich später auf bintray deployen möchte benötige ich eine einheitliche GroupId über alle Projekte hinweg. Gern hätte ich hier com.github.funthomas424242.dsl verwendet, doch das funktioniert nicht mehr falls ich mal ein Maven Plugin entwickeln sollte dann hätte ich nämlich gern die gropuId com.github.funthomas424242.maven.plugins verwendet. Damit bräuchte ich aber zwei groupId’s und das würde zwar gehen aber ist von bintray nicht gewünscht. Da man nie weiß wann solche Wünsche mal in Vorgaben umgewandelt werden (besonders wenn man die kostenlosen Services nutzt) habe ich mich also für die groupId com.github.funthomas424242 entschieden. Als Folge daraus muss ich meine Projekte mit dieser groupId versehen. Damit das funktioniert und ich trotzdem noch verschieden DSL Projekte verwalten kann gehe ich wie folgt weiter vor. 

Die nachfolgenden Einstellungen im Wizard werden am Beispiel meines Projektes ahnen.dsl auf github erklärt. Und so fülle ich die erste Dialogseite des Wizards aus:

Xtext Projekt Basisdaten

 

Ja, der Projektname ist richtig. Zwar wird dieser als groupId verwendet doch lässt sich das später manuell gut abändern.

Xtext Projekt Settings

 

Als Source Layout wurde Plain gewählt da eine andere Kombination mit der Einstellung Eclipse Plugin aktuell noch nicht unterstützt wird.

Nun werden diverse Projekte vom Wizard in der eclipse erzeugt.  Von jedem Projekt öffnen wir nun die pom.xml und korrigieren die groupId manuell auf z.B. com.github.funthomas424242 Anschließend selektieren wir alle Projekte und führen ein Maven update Projekt über das Kontext Menü in der eclipse durch. Nun sollten alle Projekte wieder fehlerlos erscheinen. Falls nicht einfach die Xtext Datei öffnen und noch mal alle Sourcen generieren lassen. 

Bevor wir einen commit durchführen sollten wir noch im parent Projekt eine .gitignore anlegen. Meine sieht wie folgt aus:

.settings/
target/
src-gen/
xtend-gen/
.project
.classpath
*_gen

Man beachte, dass ich hier die führenden / (Slashes) weggelassen habe damit die Regeln auch für die Unterprojekte gelten. Nun testen wir zunächst unser Projekt indem wir eine Eclipse Instanz mit Runtime Workspace starten:

Runtime Start

 

In der gestarteten Runtime Eclipse legen wir ein einfaches Projekt „Test“ an und darin eine Datei test.ahnen. Beim Öffnen dieser Datei können wir sehen ob unser Plugin prinzipiell schon funktioniert, denn es muß der entsprechende Editor zum Öffnen angeboten werden. In meinem Fall nennt sich dieser Ahnen Editor und ist vorhanden. Verwenden wir diesen Editor zum Öffnen werden wir gefragt ob das Projekt in ein Xtext Projekt konvertiert werden soll – ja natürlich. Wir müssen nichts dazu tun eclipse trägt nun ein paar Metadaten in die Projektbeschreibungsdatei .project ein und das scheint es gewesen zu sein. Den Editor prüfen wir indem wir seine Vorschlagsfunktion unter Ctrl+Space nutzen und den ganzen Beispieltext damit eingeben.

Das war es erstmal. Jetzt können wir die Runtime Instanz der eclipse schließen und unseren Projektstand commiten (aber noch nicht pushen). Wir müssen zwar noch alle Projekte ein Verzeichnis nach oben verschieben aber das sollte git als Verschiebung erkennen und somit sollte dies kein Problem ergeben. Also commited ist.

Jetzt löschen wir alle Projekte aus unserer eclipse aber nicht auf der lokalen Festplatte!!!

Nun unbedingt die eclipse schließen da sie meist die Projekte trotzdem noch lockt und dadurch nachfolgende Schritte fehlschlagen würden. 

In einer Shell navigieren wir jetzt zum Parent Projekt (in diesem ist die pom.xml des parents zu finden) von dort aus verschieben wir alle Verzeichnisse und Dateien ins übergeordnete Verzeichnis. Anschliessend navigieren wir selber in das übergeordnete Verzeichnis und löschen das nun leere alte parent Projekt.

Jetzt ist unser normales root Verzeichnis aus dem github repository das parent Projekt und wir können es ganz normal in  unsere Eclipse neu importieren. 

Diesen Stand commiten wir ebenfalls wobei wir ihn dem letzten Commit hinzufügen (amend commit). Jetzt noch ein kurzer Test mit der Runtime eclipse. Wenn alles noch so funktioniert wie vorher, dann können wir jetzt pushen.

Maven Build anpassen

Durch die manuelle Umbenennung der groupId haben wir unser Definitionsfile der target platform invalidisiert. Das sollten wir unverzüglich beheben. Das Problem wird deutlich wenn wir im Root Verzeichnis unseres Projektes ein mvn clean install ausführen.

Das Problem lässt sich leicht korrigieren durch eine Anpassung in der parent/pom.xml. Dort muss die groupId der TargetPlatform angepasst werden. Ich bevorzuge eine generische Lösung. Anbei der relevante Abschnitt aus der parent/pom.xml:

<plugin>
 <groupId>org.eclipse.tycho</groupId>
 <artifactId>target-platform-configuration</artifactId>
 <version>${tycho-version}</version>
 <configuration>
  <target>
   <artifact>
    <groupId>${project.groupId}</groupId>
    <artifactId>com.github.funthomas424242.dsl.ahnen.target</artifactId>
    <version>${project.version}</version>
   </artifact>
  </target>

So jetzt funktioniert der Maven Build wieder. Zeit für einen neuen commit. Aber mit dem Push ruhig noch warten, den wollen wir gleich durch das CI System schicken.

Das CI System aktivieren

Dazu gehen wir auf travis-ci.org und loggen uns mit unserem github.com Account per OAuth ein. In der rechten oberen Ecke wird der Nutzername angezeigt beim überstreichen mit der Maus ploppt ein Menü auf. Daraus wählen wir den Punkt Accounts aus. Da das Repository neu ist, wird es travis-ci noch nicht kennen und wir nutzen den Sync Button oben rechts um unsere github Projekte zu importieren. In der erscheinenden Liste an Projekten suchen wir unser Projekt und aktivieren den Schalter davor. Ab jetzt sucht travis-ci bei jedem push in das Projekt eine Datei .travis.yml und falls gefunden wird anschließend ein Build ausgeführt.

Natürlich müssen wir diese Datei noch ins Projekt einchecken. Sie gehört ins parent Projekt und muss wirklich mit einem Punkt beginnen (also ein Problem für alle Windows Freunde – aber ein lösbares 🙂 )

language:
 - java

jdk:
 - oraclejdk8

Nun noch ein commit und ein push und die Maschinerie springt an 🙂 Nach ungefähr 10 Minuten sollte das Projekt in travis erscheinen und der Build lässt sich prüfen. Es empfiehlt sich ein entsprechendes Build Icon von travis in die Projekt Readme zu integrieren. So kann man auf einem Blick erkennen wenn der Status auf rot geht. 

Bintray Deployment anbinden

Zu den Formalitäten wie Registrierung und ähnliches bei bintray.com möchte ich hier nicht eingehen. Nur eins dazu das Passwort für die oss.jfrog.org Seite ist Euer API Key von bintray.com. Möglicherweise müsst ihr Euch erst freischalten lassen etc. Aber das sollte sich jeder selbst durchlesen, da es teilweise auch Sicherheitsrelevant ist.

Weiterhin ist bei maven die settings.xml anzupassen. Hier sind die Zugangsdaten für den Server zu hinterlegen. Vorsicht – die Datei darf kein Anderer in die Hände bekommen. Idealerweise nutzt ihr die Verschlüsselungsmechanismen. 

Im Projekt ist auch noch eine Anpassung durchzuführen. Die Deplyoment Repositories sind im parent/pom.xml bekannt zu geben. Dazu fügen wir folgenden Eintrag in die parent/pom.xml ein.

<distributionManagement>
 <snapshotRepository>
  <id>snapshots</id>
  <name>oss-jfrog-artifactory-snapshots</name>
  <url>https://oss.jfrog.org/artifactory/oss-snapshot-local</url>
 </snapshotRepository>
 <repository>
  <id>bintray-funthomas424242-dsl</id>
  <name>oss-jfrog-artifactory-releases</name>
  <url>https://oss.jfrog.org/artifactory/oss-release-local</url>
 </repository>
</distributionManagement>

Mit einem mvn deploy lassen sich ab jetzt Snapshots und Releases nach oss.jfrog.org deployen. Von dort aus können diese im angemeldeten Zustand über das Kontextmenü nach bintray.com in ein beliebiges Package kopiert werden. Jedes Package muss auf bintray in einem Repository liegen. Ein Package welches im jCenter veröffentlicht werden soll muss einigen Anforderungen genügen (mindestens ein jar, ein src.zip, ein pom.xml und optional noch ein javadoc archive). Die Freischaltung für das jCenter dauert ein wenig Zeit – am besten rechnet man mit 24h – und erfolgt nur auf Antrag. Eine weitere Freischaltung für das maven central erfordert dann noch ein Sonatype Login. Parallel zur Beantragung der ganzen Accounts kann dann schon mal Fachlichkeit umgesetzt werden 🙂

Noch ein paar Tipps

  1. Tycho kann bereits in der Version 0.25.0 benutzt werden. Das muss man manuell in der parent/pom.xml in den Properties eintragen. 
  2. Um das Deployment zu verringern nutze ich in der parent/pom.xml:
    <maven.deploy.skip>true</maven.deploy.skip>
    und in der pom.xml des repository Subprojektes:
    <maven.deploy.skip>false</maven.deploy.skip>
    So wird nur das Zip mit der eclipse update site hochgeladen.

Soweit zum Aufsetzen eines DSL Projektes und viel  Spass beim Ausprobieren. Jetzt muss nur noch die Fachlichkeit umgesetzt werden 😉

 

GUIs deklarativ – never ending story


Flattr this

Motivation

Der Traum eine Programmoberfläche möglichst einfach, mit wenig Text und doch mit exakter Anordnung der GUI Elemente beschreiben zu können ist schon sehr alt. Immer wieder tauchten dazu Konzepte auf – doch diese konnten sich am Markt nie wirklich fortsetzen, nicht zu Letzt auch mangels der Unterstützung großer Firmen. Das letzte mir bekannte Exemplar ist JavaFX Script welches nun auch schon fast als ausgestorben bezeichnet werden kann.

Für alle die sich dennoch eine deklarative Sprache für die GUI Entwicklung wünschen zeigt dieser Artikel Projekte und mögliche Fortsetzungen auf.

Thinlet

Das erste mir bekannte Projekt welches seine GUI deklarativ beschrieb war Thinlet. Ich nenne es mal Thinlet one denn der Autor hat das Projekt inzwischen eingestampft und hat unter gleichem Namen ein völlig neues Framework herausgebracht. Letzteres konnte mich aber nicht weiter begeistern.

Das ursprüngliche Projekt war im Prinzip ein Jar mit einer Klasse. In dieser Klasse war die gesamte Logik. In der eigenen Anwendung waren die Oberflächen dann per xml zu beschreiben. Das Framework unterstützte sogar bereits das Binding von GUI Elementen an Java Klassen. Allerdings war das Eventhandling irgenwie nicht optimal gelöst – ich hatte damit jedenfalls Probleme – ich glaube mit der Richtung aus Java Klasse zum GUI Element oder von GUI Element zu GUI Element. Das kann ich leider nicht mehr genau sagen.

Dokumente zum ursprünglichen Projekt lassen sich kaum noch finden – man muss halt ein bisschen googeln denn die URLs wechseln stetig – aber offensichtlich gibt es noch genug Leute welche die Dokumentation retten. Hier ein Beispiel: http://wolfpaulus.com/thinlet/doc/widget/overview.html

Canoo

Diese Firma muss ich hier einfach aufzählen, weil sie mit ULC (Ultra Light Client) das fertiggestellt hat von dem alle Welt träumt. Allerdings proprietär und teuer 😦 Das war der Grund weshalb ihr Framework für den Open Source Bereich nicht in Frage kommt. Aber die Technologie ist genial – Half Object Plus Protocol (HOPP) Entwurfmuster. Das wäre das Ziel nur eben frei und Oracle hat es mit JavaFX eindeutig vermasselt. Hier ein Beispiel wie leicht alles gehen könnte.

GUI4J

Das GUI4J Projekt funktionierte ähnlich wie Thinlet wurde aber von mehr Leuten entwickelt und länger durchgehalten.

Zu guter Letzt gibt es natürlich tausende Projekte die in Richtung XML deklarierte Oberfläche gehen aber keine welches wirklich später dafür relevant wurde. Hier eine von vielen Listen die im Internet findbar sind: http://www.java2s.com/Product/Java/XML/XML-UI.htm

JavaFX

JavaFX in der ersten Version hatte mit JavaFX Script wirklich Potential den Sprung in Richtung Canoo zu schaffen. Doch Oracle hat es getötet aus welchen Gründen auch immer: http://www.heise.de/developer/meldung/Das-endgueltige-Aus-fuer-JavaFX-Script-1444903.html

JavaFX selbst hat Oracle dennoch zur Schlüsseltechnologie erhoben. Bislang steht diese allerdings irgendwo außerhalb des aktiv von Oracle gepushten ADF. ADF selbst setzt weiterhin auf Swing und eine dirty Click and Drop Oberfläche. Letztere hinterlässt in der Praxis nach einiger Zeit auch gern mal korrupte Arbeitsstände. Dann darf der Entwickler wieder zurück auf LOS ohne einen Erfolg einzustreichen. Wie soll man also die Signale aus dem Hause Oracle deuten? Möglicherweise ist sich Oracle intern selbst uneins und setzt später einfach auf die Technologie die sich durchsetzt. Einige Entwickler greifen daher selbst zur IDE und bauen schon wieder ihre eigenen RIA Frameworks:

Captain Casa Framework

Da ich dieses RIA Dilemma schon einige Zeit betrachte setzte ich immer wieder meine Hoffnung auf das Captain Casa Framework. Captain Casa ist eine Firma welche für den lokalen Mittelstand diverse Softwarelösungen erarbeitet hat. Diese basieren alle auf dem Captain Casa Framework. Diese wiederum setzte bis vor einigen Jahren ausschließlich auf Swing, sprang aber nach Erscheinen von JavaFX sofort auf diesen Zug auf. Aktuell steht wieder ein Community Treffen an und ich hoffe das es mir dieses Jahr endlich wieder möglich ist teilzunehmen und meinem kurzfristigen Urlaubsantrag zugestimmt wird. Falls ja werde ich natürlich wieder über das Treffen berichten.

Anbei ähnliche Artikel zum RIA Dilemma

VII. Captain Casa Community Meeting


Flattr this

Motivation

Seit einiger Zeit beschäftige ich mich nebenher mit der Evalutation verschiedener UI-Frameworks. Begonnen hatte ich dies mit der ersten Version von Thinlet. Bin dann auf GUI4J gekommen. Anschließend fand ich Canoo, evaluierte noch JavaFX und letztlich auch den Captain Casa Enterprise Client . Das Captain Casa Framework hat mir von den vorgenannten am Besten gefallen. So hatte ich mir dann auch gleich fest vorgenommen am Community Meeting teilzunehmen. Die dort gesammelten Eindrücke möchte ich in diesem Artikel vorstellen.

Organisation

Das VII. Captain Casa Community Meeting fand am 18.11.2011 in Eppelheim in der Wasserturmstraße 50 in den Räumen der KonSer Systems OHG statt. Organisiert wurde das Meeting vom Captain Casa Gründer Björn Müller über die RIA Gruppe der Internetplatform Xing. Das Treffen findet jährlich statt und wendet sich an Nutzer des Captain Casa Frameworks wie auch an Interessierte. Für alle Frühankommer war gegen 20:00 Uhr ein Treffen am Vortag in Heidelberg in der Lobby des Hotels „Holländer Hof“ organisiert. Anschließend Einkehr in eine Gasstätte und einen Spaziergang durch Heidelberg. Direkt am Veranstaltungstag war der Veranstaltungsraum extra für Frühaufsteher bereits ab 09:30 Uhr geöffnet und mit Kafffee und Brezeln bestückt.

Teilnehmer

Zum Community Meeting kamen vorwiegend proffessionelle Nutzer des Captain Casa Frameworks. Mein Eindruck war, dass es sich dabei sowohl um mittlere wie auch große Firmen handelt. Auch eine staatliche Einrichtung war mit einem aus meiner Sicht sehr großen Projekt vertreten.

Stimmung

Es war eine sehr harmonische Stimmung unter den Teilnehmern. Viele kannten sich bereits durch vorangegangene Treffen und tauschten rege Ihre Erfahrungen über das Framework aus. Alle äußerten sich positiv zum Einsatz des Frameworks und lobten den hervorragenden Support der Captain Casa GmbH.

Inhalt der Veranstaltung

Generell lässt sich der Inhalt in folgende Bereiche einordnen:

  • Erfahrungsberichte von Unternehmen bzw. Captain Casa Nutzern.
  • Vorstellung technologischer Neuerungen durch die Captain Casa GmbH.
  • Vorstellung aktueller Entwicklungen auf dem GUI Markt speziell im Bereich RIA und Mobile.

Für das Meeting war eine strikte Agenda von Herrn Müller entworfen wurden. Diese wurde auch Punkt genau begonnen, jedoch brachten die Vorträge einige Verzögerung in den Ablauf, so dass später einige Vorträge gekürzt und die Agenda dynamisch angepasst wurde. Alle Anpassungen erfolgten jedoch stets unter dem Gesichtspunkt „Was interessiert die Community“. Daher wurde stets auch die Community gefragt wie mit den einzelnen Punkten verfahren werden soll.

 

Einige Teilnehmer hatten Screenshots ihrer Anwendungen zu einem Wettbewerb eingereicht. Auf dieser Grundlage begann die Veranstaltung mit der Vorstellung der Teilnehmer. Jene, welche sich nicht am Wettbewerb beteiligt hatten, wurden mit ein paar persönlichen Worten ebenfalls vorgestellt. Damit waren die Teilnehmer alle untereinander bekannt, was für den Erfahrungsaustausch von großem Wert war.

Anschließend wurden die aktuellen Entwicklungen im RIA Umfeld vorgestellt und bewertet. Hierbei hat die Captain Casa GmbH klar ein Signal gesetzt zukünftig auch Androids zu unterstützen. Eine offizielle Erstversion soll es Anfang des 2. Quartals 2012 geben. Aktuell erarbeitet Captain Casa in einem Projekt mit einer Zeiterfassungsfirma die entsprechenden Bibliotheken. Die bereits existierende, interne Version der Anbindung wurde später in einem kurzen Tutorial zur Android Programmierung vorgestellt. In diesem Tutorial wurde zunächst gezeigt, wie mit den von Google vorgesehenen Werkzeugen eine Android Anwendung erstellt werden kann. Anschließend wurde gezeigt wie das Gleiche mit dem Captain Casa Enterprise Client funktioniert. Im Prinzip kein großer Unterschied, nur dass der Client dann sowohl auf mobilen Geräten wie auch auf Desktop PCs nahezu identisch läuft 🙂 Das Wort identisch wollte Herr Müller an dieser Stelle eigentlich nicht recht verwenden. Jedoch mangels Verfügbarkeit eines treffenderen Begriffes betonte er dann: Indentisch unter Berücksichtigung der Umgebungsbesonderheiten! Damit gemeint sind Besonderheiten wie Wischtechnik, Ortssensor etc.

Nachdem die aktuellen Entwicklungen am Markt betrachtet waren ging es zum nächsten Thema – Vorstellung der neuen Features. Es war eine enorme Menge von der ich hier nur besonders interessante erwähnen möchte:

  • Ein OpenStreetMap Control für die Einbettung freier Landkarten
  • Ein ScreenGraber Control zur Erstellung parametrisierbarer Screenshots
  • Ein Pivot Control welches auf der Grundlage von Apache POI ein vollständiges Excel anbietet
  • Ein TiledArea welches von Aussehen und Funktion an die Portlets von SUN erinnert

Bei CaptainCasa muss über Dinge wie Browserunabhängigkeit, identische Darstellung auf unterschiedlichen Systemen, einen möglichst kleinen UI Stack der Anwendung und über kleine Roundtrips zum Server durch Deltalieferungen kaum noch gesprochen werden, weil diese vom Framework sichergestellt sind. Aus diesem Grund möchte ich hier erwähnen, dass die Firma auch immer bestrebt ist, das Rad nicht neu zu erfinden sondern auf bestehende und erprobte Standards wie beispielsweise JSF setzt.

 

Präsentation von Kundenanwendungen

Es folgten nun diverse Präsentationen von Kundenlösungen. Hierbei stellten die einzelnen Firmen kurz das Projekt und die grundlegenden Anforderungen vor. Anschließend gab es dann einen Schnelldurchlauf durch die mit Demodaten gefüllte Anwendung. Hierbei wurden hier und da natürlich besondere Schmankl hervorgehoben.

Zwei Dinge haben mich persönlich am meisten begeistert. Zum Einen wurde ein Verwaltungssystem vorgestellt, bei dem eine Mail aus Outlook über Drag&Drop in das System fallen gelassen wurde und sofort als Dokument bzw. wenn mit Anhängen versehen sogar in Form mehrerer Dokumente im System verfügbar war. Zum Anderen haben viele Firmen das Casa Framework um eigene Controls erweitert. Diese ließen sich wie Casa eigene Contols in der gewohnten Entwicklungsumgebung verwenden. Ein solch nathlose Integration von Eigenentwicklungen habe ich selten in einem so mächtigen System gesehen. Ein Kunde wird seine Applikation sogar als SaaS anbieten. Damit kann Captain Casa dann auch zeigen wie sich das Framework innerhalb der Wolke verhält. Da aber viel auf Standards gesetzt wird sind hier eher positive Ergebnisse zu erwarten.

Die von den Kunden eingesetzten Technologie Stacks waren durchaus unterschiedlich, besaßen jedoch auch Gemeinsamkeiten. Eine häufige Kombination war Tomcat als Webcontainer für JSF und Hibernate zur Realisierung der Persistenz. Ab und an wurde noch ein EJB Container in Form von JBOSS seltener Classfish ergänzt. Bei den verwendeten Datenbanksystemen war es bunt gemischt. Vom Platzhirsch Oracle über MSSQL Server bis PostgreSQL war vieles vertreten.

Besonders schön empfand ich es, dass einige Präsentationen nicht nur die umgesetzten Features darstellten sondern auch auf Probleme eingingen. Dies führte zu einem besonders fruchtbaren Erfahrungsaustausch, da andere Kunden die gerade dabei waren ähnliche Wege zu beschreiten gleich prüfen konnten ob bei ihnen ein mögliches Risiko bestand. Vor allem aber konnten sie sich Tipps holen wie das Problem vermieden werden kann.

Captain Casa und Open Source

Die Captain Casa GmbH scheint generell eine Open Source freundliche Firma zu sein. Was jetzt nicht heißt, dass das Casa Framework Open Source Software sei. Nein – das nicht. Der Bezug des Quelltextes wird erst bei entsprechender, kostenpflichtiger Lizensierung möglich. Aber es sind Open Source Produkte wie Open Office und Thunderbird intern im Einsatz. Was in anderen Firmen ja teilweise undenkbar ist. Erkennbar war dies in den Vorbereitungspausen zu einzelnen Präsentationen.

Außerdem stellt Captain Casa eine freie Binary Lizenz für Entwickler bereit. Auf Wunsch kann diese auch in Form eines Dokumentes bereitgestellt werden. Diese Lizenz ist nicht exklusiv und ohne Garantien. Der Quellkode ist nicht dabei, das Logo darf nicht ausgeblendet werden aber die damit erstellten Programme dürfen mit den enthaltenen Casa Binaries verbunden an die Endnutzer weiter gegeben werden. Gerade dies ist aus meiner Sicht ein ganz wichtiger Punkt für die Entwicklung von Anwendungen im Open Source Bereich.

In der Lizenzpolitik unterscheidet sich Captain Casa damit entschieden von anderen Konkurrenzprodukten. Auf Grundlage meiner persönlichen Erfahrungen kann ich hier nur mit Canoo vergleichen. Letztlich war es die Lizenzpolitik von Canoo weshalb ich deren Framework nicht umfangreich evaluieren konnte und mich so gegen dessen Verwendung entscheiden musste. Auch einige Kunden von Captain Casa hatten zunächst Vaadin, JavaFX sowie Canoo evaluiert und sich schließlich für Captain Casa entschieden.

Schlußwort

Zusammenfassend habe ich den Eindruck erhalten, dass es sich beim Captain Casa Enterprise Client um ein sehr gutes, solides und fantastisches Framework handelt.

Hinweise und Kommentare zum Artikel sind wie immer ausdrücklich erwünscht.

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&#8216;)/][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

DSL Tutorial – Teil 1


Flattr this

Motivation

Nachdem ich letztens in [EMFText einsetzen] einen Blick auf EMFText geworfen hatte möchte ich nun die Erfahrungen welche ich inzwischen mit dem Framework sammeln durfte in einem kleinen Tutorial zusammenfassen. Dieses werde ich an einem kleinen Beispiel durchführen, in welchem eine primitive DSL für die Erstellung von svg Grafiken erstellt werden soll. Wer tatsächlich Bedarf an einer solchen DSL hat, kann die DSL dann selbständig erweitern. Es würde mich freuen, wenn solche Projekte unter dem Artikel kurz kommentiert werden – es genügt ein Link auf das Projekt 🙂

Vor dem Einstieg in mein Tutorial empfehle ich die Abarbeitung des Original ScreenCast hier: http://www.emftext.org/index.php/EMFText_Getting_Started_Screencast
So sind die wesentlichen Grundbegriffe schon bekannt und ich kann auf spezielle Punkte eingehen.

Das Tutorial wird in 2 Teilen realisiert:

  1. Teil: Erstellen und Anpassen einer DSL in Iterationen auf Basis von Eclipse und den EMFText Plugins

  2. Teil: Erstellen eines Generators für die DSL auf Basis von Eclipse und den Acceleo Plugins

Aufsetzen der Arbeitsumgebung

 

1) Download Eclipse Classic Version von:
http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.7.1-201109091335/eclipse-SDK-3.7.1-win32.zip

In der eclipse.ini setzen wir folgende Werte:

-vmargs
-XX:MaxPermSize=256m
-Xms128m
-Xmx512m

2) Start der Eclipse und Einrichten folgender Update Sites:

  1. EMFText Updates Site – http://www.emftext.org/update_trunk
  2. Eclipse Indigo Updates – http://download.eclipse.org/releases/indigo (sollte bereits eingerichtet sein)

3) Installieren der aktuellen Versionen von:

  • EMFText über den 1. URL und dann Auswahl Paket EMFText.
  • Acceleo und EcoreTools über den 2. URL und dann Auswahl Modeling/Acceleo SDK und Modeling/Ecore Tools

Beispielprojekt

 

Als Beispiel werde ich in diesem Artikel zeigen wie wir ein DSL Projekt aufsetzen, was alles benötigt wird und wie wir die DSL nach und nach erweitern können. Die Realisierung eines XMI Builders und die Erstellung eines Generator Projektes mittels Acceleo werden dann in späteren Artikeln beschrieben.

Los geht’s

1) DSL Projekt anlegen

  1. Neu/Projekt/EMFText/EMFText Projekt
  2. Felder im Dialog befüllen

001 NewEMFTextProject

 

Weiter mit Finish

2) Ecore Diagramm aus dem Model erstellen

Dazu suchen wir im DSL Projekt den Ordner metamodel, selektieren dort das Ecore Model svgd.ecore und dann über das Kontextmenü den Punkt Initialisiere Ecore Diagramm File auswählen.

003 EcoreDiagram

Den anschließenden Dialog mit Finish bestätigen. Als Ergebnis finden wir eine neue Datei svgd.ecorediag . Diese wird auch gleich geöffnet und das aktuelle Ecore Model als Grafik angezeigt. Der Wizard war zu uns nett und hat schon ein paar Modelelemente für ein ER Model angelegt. Diese nutzen wir gleich weiter, passen sie aber unseren Bedürfnissen an:

  1. Type benennen wir in Form um (selektieren und in der Properties View den Namen ändern).
  2. DataType wird in Rechteck umbenannt (nach jedem Schritt am besten speichern – Obacht! Das Fenster muss als gespeichert markiert werden – also kein * mehr)
  3. EntityModel wird zu SVGModel und
  4. Entity wird zu Kreis
  5. Die Kante von Kreis zu Feature wird entfernt
  6. Das Attribut abstract in Kreis wird entfernt
  7. Die Kante von Feature zu Form wird entfernt
  8. Feature wird in Linie umbenannt
  9. FeatureKind wird in Linienart umbenannt
  10. attribute in Linienart wird zu durchgezogen, reference zu gestrichelt und containment zu gepunktet umbenannt (Bitte stets Name = Literal setzen)
  11. Alles Speichern und das ecore Model svgd.ecore öffnen und prüfen ob die Änderungen auch hier korrekt durchgeführt wurden.

An dieser Stelle sehen wir, dass es nicht ganz geklappt hat. Kreis enthält noch eine Verbindung features zu Linie – die muss natürlich weg. Ein wichtiger Schritt beim iterativen Vorgehen immer Diagramm gegen Ecore Model vergleichen! Letztlich ist das Ecore Model der Master für alle Modellierungswerkzeuge.

 

Also jetzt erstmal im Ecore Model aufräumen:

  1. features unter Kreis entfernen
  2. type unter Linie entfernen
  3. kind unter Linie umbenennen in stil
  4. Super von Linie (NamedElement) wechseln und dafür Form auswählen
  5. types unter SVGModel umbenennen in elements

004 FertigesEcoreModell

 

Nun alles Speichern und ins Ecore Diagramm zurück wechseln. Nach dem Wechseln in das Ecore Diagramm, stellen wir fest, dass einige Änderungen nicht korrekt dargestellt werden. Bei umfangreichen Änderungen im Ecore Model passiert dies leider immer wieder. An dieser Stelle empfielt es sich das Diagram zu löschen und wie oben bereits durchgeführt erneut aus dem Ecore Model zu erzeugen. Einen effizienteren Weg habe ich hierfür leider nicht gefunden. So schaut das neu erstellte Diagramm aus.

005 FertigesEcoreDiagram

Da die Anpassungen auch für das GeneratorModell und die HUTN Syntax zu umfangreich waren, werden wir auch diese beiden Dateien neu erzeugen (Später werden wir diese Schritte teilweise automatisch ausführen lassen).

Zunächst aktualisieren wir das Generator Model. Also Rechtsklick auf svgd.genmodel und Reload auswählen. Im Wizard dann Ecore Model auswählen. Auf der nächsten Tab das konkrete Modell auswählen (Der korrekte Pfad sollte bereits hinterlegt sein). Kurzer Klick auf Load und dann geht es auf Weiter . Zum Abschluss Finish und es ist geschafft.

006 ReloadGenModel

Nun löschen wir das Syntax File svgd.cs und erzeugen uns ein Neues. Also nach dem Löschen bitte einen Rechtsklick auf svgd.genmodel und den Eintrag generateSyntax/HUTN-Syntax ausgewählt. Erledigt.

007 GeneriereHutnSyntax

Jetzt schauen wir uns die Syntax an. Die entstandene Datei sollte wie folgt aussehen.

008 FertigeHUTNSyntax

Die Syntaxdefinition ist recht rudimentär und wir müssen sie zunächst ein wenig an das Metamodell anpassen bzw. ein paar erleichternde Optionen einfügen.

Fangen wir mit den Optionen an welche uns die iterative Arbeit künftig erleichtern werden – dazu folgenden Abschnitt vor TOKENS einfügen.

OPTIONS{
reloadGeneratorModel=“true“;
generateCodeFromGeneratorModel=“true“; //wichtig um Fehler im Generat zu vermeiden
disableLaunchSupport=“false“;
usePredefinedTokens=“true“;
}

Anschließend generieren wir die TextResourcen.

 

009 GeneriereTextResourcen

Nun müssen wir noch die alten, vom NewWizard erzeugten Klassen entfernen:

  • DataTypeImpl

  • EntityImpl

  • EntityModelImpl

  • FeatureImpl

  • TypeImpl

010 KlassenEntfernen

 

Alles rot markierten Klassen sind zu entfernen – das sind Rückstände aus früheren Iterationen oder vom Neu Anlegen Dialog.

Starten wir nun das Projekt über Run As Eclipse Application können wir in der sich öffnenden Runtime-Eclipse über den Neu Wizard ein Projekt vom Typ svgd anlegen. Das gleich mit angelegte File new_file.svgd unterstützt bereits unsere HUTN Syntax mit einem leistungsfähigen Editor inklusive automatischer Syntaxvorschläge und farblicher Syntaxauszeichnung.

011 SimpleModelInstanz

Allerdings ist die Syntax nicht wirklich tauglich eine Vectorgrafik zu beschreiben. Damit sich dies ändert, werden wir nachfolgend die Syntax und falls notwendig auch das Ecore Modell nach und nach erweitern und anpassen.

Bis hierher eine kleine Zusammenfassung als Video

SVG – die fachliche Domain

Wenn man eine DSL erstellt, sollte man sich auch in der fachlichen Domain auskennen. Einen guter Einstieg für den Bau einer DSL findet sich auf Wikipedia unter [SVG]. Für uns ist wichtig welche Grundelemente der Sprache es gibt und welche Attribute diese besitzen müssen. Da SVG nur wenige Elemente definiert werden diese im Folgenden kurz aufgezählt:

  • Pfad …
  • Kreis definiert über Mittelpunkt und Radius
  • Ellipse definiert über Mittelpunkt und Radius1 sowie Radius2
  • Rechteck definiert über Position der linken oberen Ecke sowie Breite und Höhe
  • Linie definiert über die Positionen der beiden Endpunkte
  • Polygonzug definiert über eine Liste von Positionen der Punkte
  • Polygon definiert über eine Liste von Positionen der Punkte
  • Text …
  • Image …

Zu jedem Element lassen sich noch Style und Transformationsangaben hinterlegen. Für unsere DSL sollen die 3 Grundelemente (oben in fett) ohne Style und Transformationen genügen.

 

DSL erweitern

Die Grundelement Kreis, Rechteck und Linie sind in unserer DSL bereits definiert. Was fehlt sind Attribute der Grundformen. Also gleich ins Ecore Diagram und die benötigten Attribute wie folgt definiert.

  • Kreis um die Attribute x und y sowie radius ergänzt. Alle vom Datentyp EFloat.
  • Rechteck um die Attribute x und y sowie hoehe und breite ergänzt. Alle vom Datentyp EFloat.
  • Linie um die Attribute x1 und y1 sowie x2 und y2 ergänzt und auch diese alle vom Datentyp EFloat .

Das finale Ecore Diagramm sollte wie folgt aussehen.

 

012 FinalesEcoreDiagram

Da diesmal nur Objekte hinzugefügt wurden, sollte kein Unterschied zum Ecore Modell entstanden sein. Vorsichtshalber aber ruhig vergleichen ob das Ecore Modell dem Ecore Diagramm entspricht. Gegebenenfalls natürlich anpassen.

Auf jeden Fall sollten wir jetzt eine Syntax definieren in welcher eine sinnvolle Beschreibung der Grafik möglich ist. Dazu öffnen wir die Syntaxdefinition sgvd.cs und führen folgende Anpassungen durch.

  • Zunächst entfernen wir die extra definierten Token. Diese benötigen wir nicht! Wir beschränken uns auf die von EMFText vordefinierten Standardtoken (siehe Option: usePredefinedTokens)
  • Nun passen wir die Syntax-Regel für das Rechteck an:
    Rechteck ::= „Rechteck“ „{“ „name=“ name[‚“‚,'“‚] „x=“ x[‚“‚,'“‚] „y=“ y[‚“‚,'“‚] „höhe=“ hoehe[‚“‚,'“‚] „breite=“ breite[‚“‚,'“‚] „}“;
  • Weiterhin ist die Syntax-Regel für Kreis wie folgt anzupassen:
    Kreis ::= „Kreis“ „{“ „name=“ name[‚“‚,'“‚] „x=“ x[‚“‚,'“‚] „y=“ y[‚“‚,'“‚] „radius=“ radius[‚“‚,'“‚] „}“;
  • Die Zeichenkette „elements“ im SVG Modell ist auch überflüssig also die Regel für SVGModel angepasst:
    SVGModel ::= „SVGModel“ „{“ (elements)* „}“;
  • Schlussendlich muss auch Linie noch angepasst werden:
    Linie ::= „Linie“ „{“ „name=“ name[‚“‚,'“‚] „x1=“ x1[‚“‚,'“‚] „y1=“ y1[‚“‚,'“‚] „x2=“ x2[‚“‚,'“‚] „y2=“ y2[‚“‚,'“‚] „stil“ „:“ stil[durchgezogen:“durchgezogen“, gestrichelt:“gestrichelt“, gepunktet:“gepunktet“] „}“;

Zum Schluss nehmen wir noch den angebotenen Quickfix in Anspruch und lassen den ungenutzten Resolver entfernen. Schon steht die neue Syntax. Die finale Syntaxdefinition sollte wie folgt aussehen.

 

013 FinaleSyntax

Über einen Start des DSL Projektes als Eclipse Application lässt sich nun bereits eine SVG Grafikbeschreibung wie die Folgende formulieren.

014 FinaleSyntaxInstanz

Anbei noch die letzten Schritte als Video zusammengefasst.

Damit ist der erste Teil des Tutorials beendet. Ich hoffe es hat Spaß gemacht zu sehen wie einfach eine eigene DSL geschrieben werden kann. Nun wünsche ich viel Freude beim Ausprobieren und Schreiben Eurer eigenen DSLs. Falls Ihr zu dem Thema Open Source Projekte im Internet startet würde ich mich über einen Kommentar mit Link zum Projekt freuen.

Im nächsten Teil des Tutorials [DSL-2] werden wir mittels Acceleo für die hier definierte DSL einen Generator bauen. Mit dem Generator sind wir dann in der Lage aus einer Grafikbeschreibung in unserer DSL per Rechtsklick eine svg Datei zu erzeugen. Richtig Sinn macht dieses Vorgehen natürlich erst, wenn die DSL leistungsfähiger als ein herkömmlicher SVG Editor ist. Eine solche Erweiterung ist aber zu groß für dieses Tutorial. Von daher probiert doch einfach selbst aus die DSL um Konstrukte zu erweitern, mit denen Grafikobjekte zu neuen Objekten gruppiert werden können. Wird eine entsprechende große Bibliothek aufgebaut, ist es dann auf diese Weise recht einfach komplexe Grafiken in SVG zu erstellen.

Weiter geht es mit [DSL-2].

Quellennachweise

 

[DSL-2]
https://funthomas424242.wordpress.com/2011/10/16/dsl-tutorial-teil-2/
[EMFText einsetzen]
Entwickler Blog auf www.funthomas424242.wordpress.com
[SVG]
href=“http://de.wikipedia.org/wiki/Scalable_Vector_Graphics&#8220;
[EMFText Screencast]
http://www.emftext.org/index.php/EMFText_Getting_Started_Screencast

EMFText einsetzen


Flattr this

Motivation

Auf der Suche nach geeigneten Technologien zur Softwareproduktion am Fließband bin ich über Xtext nun auf EMFTText gestossen. EMFTText scheint eine weitere Integration von Xtext in die Eclipse Umgebung zu sein. Grund genug einmal damit zu spielen und ein Gefühl für das neue Werkzeug zu entwickeln.

Erster Eindruck

Nachdem ich meinen uralt Eclipsestand (Helios mit EMF 2.5.0) manuell recht umständlich aktualisiert hatte, bin ich nun im Besitz einer Eclipse Indigo mit EMFTText 1.4.0. Das hätte ich auch einfacher haben können wenn ich EMFTText gekannt hätte und einfach nach Anleitung vorgegangen wäre.

 

Nachdem ich das Tutorial durchgearbeitet hatte, war ich beeindruckt und würde die für mich wichtigen Features wie folgt beschreiben:


  • Kernpunkt der Modellierung stellt ein ecore Modell dar
  • Alles was zur Modellierung benötigt wird stellen zusätzliche Plugins bereit (Ecore Tools). So kann auf der Grundlage von Diagrammen und DSLs gearbeitet werden ohne direkt im ecore Modell hantieren zu müssen.
  • Für jeden Schritt in der Modellierung gibt es passende Generatoren und Werkzeuge.
  • Es gibt neue EMFTText Projektarten. Wie das Tutorial beweist, kommt man aber auch zu Fuß über normale Java Projekte ans Ziel (auch sehr einfach).
  • Die Beschreibung der DSLs erfolgt bei EMFTText wieder deutlich mehr an den Grundlagen der Compilertechnik orientiert als bei Xtext. Hier sieht man wieder Tokendefinitionen und Grammatikregeln. Wer mit lex und yacc angefangen hat und sich über LIGA, LIDO, GAG und Eli freuen konnte, der fühlt sich sofort wieder heimisch.
  • Auch dieses Eclipse Tool hat sich wieder nicht an der Standard Maven Directory Struktur orientiert. Packages werden wieder unter ${base}/src und ${base}/metamodell angelegt obgleich ${base}/src/main/java genauso super wäre.
  • Eine Anpassung an Maven ist aber mit der aktuellsten Version von EMFTText möglich. Dazu kann man in der Sprachdefinitionsdatei (*.cs) beispielsweise folgende Optionen setzen:

    OPTIONS{
    srcFolder = "src/main/java";
    srcGenFolder = "target/generated-sources/java";
    uiSrcFolder = "src/main/java";
    uiSrcGenFolder = "target/generated-sources/java";
    }

    Die aktuellste Version von EMFTText  bekommt man durch Einbinden der folgenden Update Site in Eclipse: http://www.emftext.org/update_trunk
  • Eine generell gute Idee scheint es zu sein in folgender Reihenfolge (wie im Tutorial) vorzugehen:

    1. Erstellen eines ecore Modells über den Ecore Diagram Editor
    2. Erstellen eines Ecore GeneratorModels aus dem Ecore Modell
    3. Generierung einer HUTN Syntax aus dem GeneratorModel
    4. Anpassen der HUTN Syntax um komplett konform zum Ecore Modell zu sein
    5. Nutzung des entstandenen DSL Editor Plugins um Texte in der neuen DSL zu schreiben.

Details am Beispiel zur Arbeit mit EMFText

Für das Spielen und zum Sammeln von Erfahrungen habe ich das ERM-DSL Projekt auf sourceforge.net verwendet. Die Quellen sind für jeden zugänglich und können unter svn://svn.code.sf.net/p/ddd-tools/erm-dsl/svn/trunk mittels subversion ausgescheckt werden.

Auswirkung der Namensvergabe

Für mich ist es in speziellen Fällen nicht leicht nach zu vollziehen wie sich die im ecore Modell verwendeten Bezeichner genau auf die Generierung auswirken. Anbei die Auflistung der beim Spielen beobachteten Auswirkungen:

 

Im verlinkten Kommentar gibt es einige Details zu diesem Thema: https://funthomas424242.wordpress.com/2011/08/16/emftext-einsetzen/#comment-28. Persönlich bevorzuge ich das Setzen der Namen über die Sprachdefinitionsdatei (*.cs). Dafür eignen sich folgende Optionen:


  • basePackage
  • uiBasePackage
  • resourcePluginID
  • resourceUIPluginID

Iteratives Arbeiten

Ich habe mit Hilfe des EMF Diagram Editors zunächst eine sehr simple Sprache mit wenigen Sprachelementen entworfen. Anschließend auf der Basis des ecore Modells ein EMF Generator Model erstellt und daraus ein HUTN Syntax File erzeugen lassen. Die Syntax habe ich noch ein bischen auf das ecore Modell abgestimmt und dann daraus die Projekte generieren lassen. Scheinbar wird der selbe Generator gestartet wenn ich auf das Generator Modell gehe und per Rechtsklick „Alles Generieren“ wähle. Anschließend die Runtime Eclipse gestartet und das DSL Editor Plugin getestet -> funktioniert 🙂

 

Jetzt soll die Sprache natürlich erweitert werden. Also wieder ins EMF Diagram, dort ein paar Änderungen durchgeführt und abgespeichert. Dann Rechtsklick auf das EMF Generator Modell „Reload“ von dem bestehenden ecore Modell durchführen. Schon ist das aktualisiert. Jetzt ins Syntax File und die Regeln für die neuen Konstrukte eingefügt – fertig. Wieder alles generieren lassen und? Einiges ist rot. Löschen und neu generieren hilft – komisch. Kurzer Test in der Runtime Eclipse – Editor funzt.

Ergo, nach Syntaxänderungen wird nicht alles was vorher erzeugt wurde wieder gelöscht. Macht Sinn, da manche Dinge nur einmal generiert werden sollen. Dennoch händisch weg löschen ist störend. Hier such ich noch nach einem Automatismus. Eine anderswo gesehene Lösung bestand darin, die Folder Struktur anzupassen. Also in 3 Arten zu unterteilen:


  • src Folder – alles handgeschrieben, nichts generiertes
  • src-gen Folder – alles wird vor der Generierung gelöscht und dann neu generiert
  • src-gen-one Folder – alles wird generiert aber nichts überschrieben und nichts gelöscht (also jedes Artefakt wird beim ersten Mal generiert und dann nie wieder)

Ob das Sinn ergibt wird sich zeigen. Hier bin ich noch am Ausprobieren. Was auf jeden Fall Sinn macht, wenn die DSL noch stark unter Entwicklung ist, sind folgende Optionen in der Sprachdefinitionsdatei (*.cs):

OPTIONS{
reloadGeneratorModel="true";
generateCodeFromGeneratorModel="true";
}

Damit wird das GeneratorModel vor dem Erzeugen der Text Ressourcen neu aus dem ecore Modell erstellt und es wird aus dem GeneratorModel heraus generiert.

Kodegenerierung

Die Kodegenerierung funktioniert über Builder. Bei der Generierung der DSL Ressourcen werden bereits Stubs für diese Builder mit erzeugt. Das Überschreiben dieser Stubs kann mittels folgender Optionen in der Sprachdefnitionsdatei (*.cs) abgeschaltet werden:

OPTIONSÂ {
overrideBuilder = "false";
}

Dadurch kann man die Logik der Builder implementieren ohne das ein neuer Generatorlauf diese Änderungen überschreibt.

 

Persönlich finde ich es allerdings eleganter ein separates Plugin Projekt für den Generator zu erstellen und dort von diesen Buildern abzuleiten. So kann sichergestellt werden, dass die Implementierung der Stubs immer zur DSL passt. Außerdem lässt sich so auch die Generator Entwicklung von der DSL Entwicklung trennen. Dies ist nützlich wenn die Arbeit auf mehrere Teams verteilt werden soll. Dann können die neuen Sprachfeatures in einem Sprint vom Team A implementiert werden und der Generator wird im nachfolgenden Sprint vom Team B überarbeitet.

Sehr erfreulich finde ich in diesem Zusammenhang die Tatsache, dass ein solches Generator Projekt im Handumdrehen aufgesetzt werden kann, da es sich um eine Ankopplung an den Standard Extension Point org.eclipse.core.resources.builders handelt. Die Erstellung eines solchen Projektes ist per Wizard über Eclipse Bordmittel möglich. Dabei werden der Builder, eine Nature, eine MenuAction und ein Marker erstellt. Benötigt wird eigentlich nur die Nature und der Builder. Die MenuAction für ToggleNature kann einfach in der Checkbox des Wizards abgewählt werden. Allerdings ist es ohne diesen Menüeintrag nicht mehr so einfach den Builder an ein bestimmtes Projekt zu binden. Letzlich muss man den Marker Extension Point einfach in der Plugin.xml löschen. Jetzt noch die zugehörigen Klassen entfernen und schon steht das Grundgerüst für den Builder. Anschließend noch die eigene Builder Klasse von [DSL]BuilderAdapter.java ableiten und schon kann der Generatorbau beginnen.

Um nicht alles manuell implementieren zu müssen, macht es Sinn den Generator selbst als Xtend oder Acceleo Projekt zu implementieren. Hier sind 2 Aspekte zu beachten:


  1. Erstellung des Generatorprojektes. Dies kann auf Grundlage des ecore Model (Metamodell der neuen DSL) statisch sowohl über Xtend als auch Acceleo erfolgen. Vermutlich lohnt sich hier die Generierung, da das Grundgerüst für ein Generatorprojekt vermutlich sehr stabil gehalten werden kann und nur die Templates von DSL zu DSL verändert werden müssen. Diese Templates könnte man in einem separaten Ordner ablegen der nicht generiert wird.
  2. Generierung der Zielartefakte aus einer Modellinstanz der DSL. Hier reden wir über die Laufzeitumgebung unseres DSL Editors. Also einen Zeitpunkt in dem wir mit dem Editor Texte in der von uns definierten Sprache erstellen können, mit Syntaxauszeichnung und Eingabeassistenten – das konkrete Model aber nur im Speicher vorliegt. Die einzige zu dieser Zeit existierende externe Repräsentation des konkreten Modells ist die Textdatei verfasst in unserer DSL.
    Ein Generator muss also an die Extension Points des DSL Editors andocken um das konkrete Modell auszulesen oder die ganze DSL Datei selbst parsen und transformieren. Hierfür dient uns der Builder welcher vom EMFText Framework generiert wurde. Zusätzlich müssen wir hier entweder mit Xtend oder mit Acceleo einen konkreten Generatorprozess implementieren. Wichtig ist, es geht stets um InMemory Modelle aus denen generiert werden soll. Letzteres ist ein Punkt der nicht immer sofort ins Auge fällt, da die Beispiele der Frameworks stets auf eine vorhandene ecore oder UML Datei basieren. Doch zur Laufzeit ist eben keine ecore Datei mehr vorhanden, da diese ja nur das Metamodell unserer DSL enthält und sämtliche Informationen in Plugin Kode überführt wurden.
    Nachdem ich es mal mit Acceleo probiert habe, bin ich der Meinung das es nicht so geeignet ist. Acceleo benötigt ein MetaModel (ecore geht) und ein Model in xmi (unsere DSL in XMI). Letzteres geht natürlich, dürfte aber aufwendig sein. Also Acceleo doch nur für Punkt 1 einfach einsetzbar.

Bewertung

Insgesamt macht das Framework einen sehr guten und durchdachten Eindruck. Die Lernkurve erschien mir recht steil. Das liegt nach meinem Empfinden aber weniger am Framework als mehr an der DSL Technologie allgemein. Wenn man die DSL Technologie allerdings mit den klassischen Methoden der Compilertechnik vergleicht, dann stellen Frameworks wie EMFText oder Xtext praktisch ein Paradies an Werkzeugen bereit.

 

Hinsichtlich einer Werkzeugstraße für industrielle Softwareentwicklung vom Fließband stellt EMFText eindeutig einen Grundbaustein dar. Vor allem auch weil durchweg bereits bestehende Quasi-Standards genutzt und nicht neu erschaffen werden.

Weiterführende Links

Ähnliche Technologien

Ganz nett fand ich auch folgenden Artikel Elinson, S.; Hanns, M. & Kronseder, S. (2010), ‚Für die Sprachenvielfalt – Xtext 1.0: Tiefere Integration in Eclipse‘, Java Magazin (10) , 76 – 78 .

Placemarks in GoogleMaps via KML importieren


Motivation

Vor kurzem habe ich 2 Artikel über Geodaten Systeme gelesen. Im Ersten [bachmann2010] ging es um ein Java API zur Verarbeitung von KML Dateien [KML Tutorial]. KML ist ein XML Format welches Google zur Verarbeitung von Geodaten benutzt. Um es sinnvoll anwenden und testen zu können wird  auf dem lokalen PC eine Installation von Google Earth benötigt. Beim Zweiten [SchiDro2010] ging es um Apache’s Searchengine Lucene in Verbindung mit Suchen über Geodaten. Die Lektüre von [SchiDro2010] kann sehr inspirierend sein in Bezug auf neu zu entwickelnde Anwendungen im Web 2.0 bzw. Social Web.
Heute nun habe ich auf Google Maps einen Link zum Import von KML Dateien gefunden. Damit lassen sich alle Artikel zu einer brauchbaren Kombination zusammenfügen. So werden wir also im Rahmen dieses Artikels ein Landmark in Google Maps unter „Unsere Karten“ importieren und speichern.

Durchführung

  1. Als erstes installieren wir [Google Earth], damit wir lokal unsere KML Dateien testen können.
  2. Dann laden wir von [KML Tutorial] eine KML Beispieldatei herunter und speichern diese auf unserem lokalen PC als test.kml.
    
    
  3. Jetzt navigieren wir im Browser auf Google Maps (Es wird ein Google Account benötigt um „Meine Karten“ zu benutzen).
  4. Navigieren links auf den Karteireiter „Meine Karten“ gleich neben Route.
  5. Jetzt den Link „Neue Karte erstellen“ benutzen.
  6. Hier wird nun der Link „Importieren“ sichtbar. Über diesen einfach obige Beispieldatei hochladen.
  7. Dann auf Fertig und falls notwendig auf Speichern.

Voila schon haben wir ein Landmark in Google Maps persistiert. Im Gegensatz zu Google Earth ist dieses Landmark tatsächlich kein temporäres sondern lässt sich auch später noch unter „Meine Karten“ aufrufen.

Ein paar weitere Dinge die so gehen kann man hier betrachten: http://maps.google.com/maps?f=q&hl=en&q=http%3A%2F%2Fkmlscribe.googlepages.com%2FSamplesInMaps.kml&ie=UTF8&ll=36.879621,-53.4375&spn=103.772916,208.476563&z=2&om=1

[Google Earth]
http://www.google.de/intl/de/earth/index.html
[JAK KML Tutorial]
http://labs.micromata.de/display/jak/HelloKML+%28Quickstart%29
[KML Tutorial]
http://code.google.com/intl/de-DE/apis/kml/documentation/kml_tut.html
[SchiDro2010]
Schindler, U. & Drost, I. (2010), ‚Wo bin ich – Geografische Suche mit Apache Lucene‘, Java Magazin 9 , 34 – 38 .
[bachmann2010]
Bachmann, F. (2010), ‚KLM-Geodaten in Java‘, Java Magazin 10 .

Typographie in der EDV


Motivation

Nachdem im Buchdruck die Typographie seit langem bekannt ist und ihre Regeln zumeist auch beachtet werden, ist dies in der EDV speziell auch im Internet deutlich seltener der Fall. Begründen lässt sich dies zum Einen mit mangelhafter Werkzeugunterstützung und zum Anderen mit einem gewissen Teil an Unkenntnis. Doch selbst wenn einem ein paar Grundregeln bekannt sind, ist es immer wieder schwer diese dann auch anzuwenden.

Das beste Beispiel ist dieser Blog. Wenn ich die verschiedenen hier angewandten Schriftarten und Ausprägungen zähle bekomme ich das kalte Grausen. Doch wie kommt es dazu? Die Themes passen nicht recht, also werden sie gewechselt. Damit wechseln evlt. auch die Default Schriftarten und der nächste Artikel wird komplett anders aussehen. Dann werden Textpassagen aus Officedokumenten durch kopieren in den Blog übertragen und schon sind wieder neue Schriften eingetragen.

Letztlich kann auch dieser Artikel keine Lösung bieten aber er kann die Lessons Learned weitergeben. Nette Leser werden den Artikeln mit hilfreichen Kommentaren und entsprechenden Tipps versehen. Diese werde ich dann einarbeiten und so wird sich eine solide Wissensbasis angewandter Typographie in der EDV ergeben.

:

[weitere Abschnitte]

:

Hintergrundfarbe Chamois

Die in [Tschi1988] empfohlene Blattfarbe für Drucksachen nennt sich Chamois. Der Farbton ist nicht exakt definiert aber es heißt es sei kein reines Weiss sondern etwas gelblich, jedoch heller als Elfenbein. Andere Quellen sprechen von einem Weiß mit braunen Anteilen, so auch [Actoid]. In [MacTechNews] hat der Nutzer dreyfus ein chamois farbenes Papier der Marke Fomatone MG Classic 532 Nature mit dem Spectrophotometer untersucht und folgende CMYK  Werte ermittelt: C=0, M=8.68,Y=24,K=0.

Beim CMYK Farbmodell handelt es sich um das Standardfarbmodell für den Vierfarbendruck. Es ist ein subtraktives Farbmodell und wird von Druckereien sowie von modernen Heimdruckgeräten wie Tintenstrahldruckern unterstützt. Allerdings lassen sich exakte Farbvorgaben nur über den Farbwert und ein Farbprofil des Druckers beschreiben.

Beim RGB Farbmodell handelt es sich um ein Farbmodell für Bildwiedergabegeräte wie Fernseher, Monitor, Displays – also alles was irgendwie aktiv strahlt und nicht über reflektion von weissen Licht zur Farbe führt. Es handelt sich dabei um ein additives Farbmodell. Auch hier ist der exakte Farbwert nicht nur vom Farbkode sondern auch vom Wiedergabegerät abhängig. Der gleiche Farbwert angezeigt über eine TFT Bildschirm und einem Kathodenstrahler wird meist leicht differieren.

Aus obiger Beschreibung lässt sich schnell schlussfolgern, dass es recht schwierig ist einen genauen Farbwert für die Farbe Chamois anzugeben. Aus meiner Sicht ist dies auch gar nicht weiter wichtig. Wichtig ist nur die Hintergründe für die Wahl der Farbe zu kennen und diese durch die Wahl eines geeigneten Farbwertes möglichst gut zu unterstützen. Soweit mir in Erinnerung ist, waren folgende Gründe bei der Farbwahl entscheidend:

  • Ein weisses Blatt an einem heissen Sommertag unter heller Sonne betrachtet reflektiert so stark, dass es sich nur schwer lesen lässt. Daher ist es notwendig das weiss mit anderen Farbanteilen zu versetzen um möglichst das zu viel reflektierte Licht zu absorbieren.
    -> die Farbe soll unter hellem Licht nicht blenden
  • Ein ganz dunkles Blatt kann nicht verwendet werden, da sonst nicht genügend Kontrast zur Schriftfarbe beleibt und damit wiederum das Lesen erschwert wird.
    -> die Farbe soll einen guten Kontrast zur Schriftfarbe bilden
  • Als Schriftfarbe scheidet Weiß aus, da bei dieser Wahl unter heller Beleuchtung die Buchstaben stark blenden würden und ein flimmern der Schrift auftritt, welches wiederum das Lesen erschwert. Die Erfahrungen zeigen, dass Blau und Schwarztöne als Schriftfarbe geeignet sind.
    -> die Farbe soll einen guten Kontrast zu den Farben Blau und Schwarz bieten

Anbei eine Tabelle mit möglichen Farbkodierungen der Farbe Chamois in verschiedenen Farbmodellen.

 Hex RGB  CMYK
#EFE0B9
#EBE5AE #E9D4A6 #EBE5B0 #EDE6B6 #EFDFBB #FFFFDC
#FFFFCC
239,224,185
235,229,174
233,212,166
235,229,176
237,230,182
239,223,187

0,0.063,0.226,0.063
0,0.026,0.26,0.078
0,0.09,0.288,0.086
0,0.026,0.251,0.078
0,0.03,0.232,0.071
0,0.067,0.218,0.063

   
#EFE0B9
255,255,220
 0,0.063,0.226,0.063
     
     
     
     
     

Quellen

[Actoid]
Homepage eines professionellen Design Anbieters zu Farbnamen.
[Tschi1988]
Tschichold, J. (1988), Erfreuliche Drucksachen durch gute Typographie – eine Fibel für jedermann , Maro Verlag Augsburg .
[Tschi1928]
Tschichold, J. (1928), Die neue Typographie , Berlin.
[Tschi1932]
Tschichold, J. (1932), Typographische Entwurfstechnik , Stuttgart .
[MacTechNews]
Ein Beitrag von dreyfus zum Thema Farbdefinition von Chamois.

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) .