I’m currently developing a Java source generator based on UML and UML Profiles. In my profile I created a tagged value with the name „type“ and metaclass „Attribute“. After applying the stereotype to an attribute I had a lot of errors during the code generation. The error message was: „Couldn’t find operation ‚getTypeName(Common::TaggedValueType)‘ for uml::Class.Occured in: EXPAND expand:: … ::Root FOR model“ for „«getTypeName(att.type)»“. I debugged the interpreter and it seems that tagged values can override default visible attributes of the element. There should realy be a warning in the Xpand documentation.
Fixed bugs in import conflict handling and context menu integration. The context menu entry is now also visible in the context menu of the editor.
I created a new release of CQTP. It contains a bugfix for an bug in the import grouping. The fully qualified type detector collects more possible import candidates.
This release contains a bugfix to filter also imports from the same package and the root package. The Xpand integration provides a configurable sorting functionality for imports now.
Heute gab es ein paar Bug-Fixes. Außerdem lässt sich das Plugin jetzt auch außerhalb der Eclipse Runtime nutzen. Aufgund der Änderungen kann ich jetzt ein zuätzliches Plugin für Xpand anbieten. Xpand ist ein Generator-Framework zur Erstellung eigener Code Generatoren.
Xpand basierte Generatoren nutzen oft keine import-Statements, da sie nur sehr komplex erzeugt werden können und sich Importkonflikte nur durch Modeling by Convention vermeiden lassen. Es wird daher oftmals gegen vollqualifizierte Klassen generiert, was den generierten Quellcode nicht schöner macht. Das Plugin lässt sich daher verwenden, um die import-Statements nachträglich zu erzeugen. Daher bietet das Plugin eine postprocessor-Komponente an, die sich in innerhalb einer Generator-Konfiguration einbinden lässt.
Hier geht es zu den Plugins.
Das Attachment-Pattern (Attachment-Entwurfsmuster) wurde von mir im Rahmen meiner Master-Thesis entwickelt und fand relativ viel Anklang bei anderen Entwicklern, daher stelle ich es heute der Allgemeinheit vor.
Das Attachment-Entwurfsmuster gehört zu den Strukturmustern und verwendet die Komposition um eine Basisklasse um Eigenschaften und Assoziationen zur Laufzeit zu erweitern. Die folgende Abbildung zeigt das Muster und wird nachfolgend erläutert.
Das Attachment-Pattern (Attachment Entwurfsmuster)
Bestandteile
- Das AttachableObject kann um Attachment-Objekte erweitert werden und kann selbst über ein ReferenceAttachment-Object referenziert werden.
- Das Attachment ist abstrakt und muss mindestens ein Attribut beinhalten der die Art des Attachments identifiziert.
- Das PropertyAttachment wird benutzt um ein AttachableObject um ein Attribut (Property) zu erweitern. Das Attribut value vom Typ T beinhaltet den Wert des Attributes
- Das ReferenceAttachment wird benutzt um ein AttachableObject um eine Assoziation zu erweitern.
Vorteile
- Dynamische Erweiterungen zur Laufzeit. Attribute und Assoziationen die zur Designzeit noch nicht bekannt waren, können nachträglich realisiert werden, ohne eine Änderung am Code vornehmen zu müssen.
Nachteile
- Gefahr des Wildwuchses von Attachments. Dem kann entgegen gewirkt werden durch eine Komponente, welche die erlaubten Attachments verwaltet.
- Nachträgliche Integration in das Domänenmodell. Attachments sollten spätestens bei einem Major-Release der Software aufgelöst werden und in das Domänenmodell integriert werden. Dies wirkt ebenfalls der Gefahr von Wildwuchs entgegen.
Heute habe ich ein wirklich cooles Feature von XML Schema 1.1 entdeckt von dem ich bisher noch nie was gehört oder gesehen hatte. Bei der Definition von XML-Schemas bin ich schon öfters an einen Punkt gestoßen, an dem man ein Constraint für einen komplexen Datentype gerne in einem Schema unterbringen möchte, XML Schema 1.0 jedoch nicht die sprachlichen Mittel bereitstellt. Ein Beispiel für ein solches Constraint wäre:
Attribut X muss den Wert "Foobar" einnehmen, wenn Attribut Y im Wertebereich >= 20 und <= 50 liegt.
Gelöst wird dies meist entweder in dem man das Constraint in ausführbaren Code gießt oder man zusätzlich mittels einem XSLT/XPath oder Schematron Dokument validiert. Dies hat jedoch den Nachteil, dass man ein zweites Dokument erstellen muss, dass dann auch immer synchron gehalten werden müssen.
Wie ich heute gelernt habe gibt es seit XML Schema 1.1. eine Lösung für dieses Problem, das assert-Tag. Man kann mittels diesem Tags ein Constraint direkt auf einem komplexen Datentyp definieren. Hierzu benutzt man das test-Attribut. Es beinhaltet einen nach Boolean evaluierenden XPath Ausdruck. Nur wenn sowohl das Schema valide ist als auch alle Constraints nach True evaluieren, ist das Dokument valide. Um möglichst nützliche Fehlermeldungen bei einem nach False evaluierten Constraint zu erzeugen kann man z. B. das assert-Tag um das message-Attribut aus dem Xerces-Namespace anreichern.
Folgendes ungetestete Beispiel zeigt ein Schema für oben genanntes Beispiel mit passender Fehlermeldung. Wie man am Beispiel sieht wird die Evaluierung auf Basis des Eltern-Elements realisiert.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xerces="http://xerces.apache.org">
<xs:element name="example">
<xs:complexType>
<xs:attribute name="X" type="xs:string" />
<xs:attribute name="Y" type="xs:int" />
<xs:assert test="@X eq 'Foobar' and @Y >= 20 and @Y <= 50"
xerces:message="X muss den Wert 'Foobar' einnehmen, wenn ..." />
</xs:complexType>
</xs:element>
</xs:schema>
Links
- Artikel von IBM developerWorks
- Komplexeres Beispiel aus einem Beitrag von Planet Eclipse (habe das Tag hier entdeckt) | Beschreibt die Validierung von generischen Datenstrukturen.
- Vorstellung der Möglichkeiten zur Constraint Definition pre XML-Schema 1.1 (aktuelle Möglichkeiten)
- Spezifikation (Last Call Working Draft)
- Änderungen zur aktuellen Version
Hinweis
Aktuell befindet sich die Spezifikation zu XML Schema 1.1 noch im Status „Last Call Working Draft“. Es ist also sehr wahrscheinlich, dass die Spezifikation ohne große nennenswerte Änderungen als Standard übernommen wird. Der aktuell Status kann man auf der W3 Seite erfahren.
Garmin Edge 705 Frontal
Letzte Woche war es endlich soweit, ich habe mir ein Garmin Edge 705 zugelegt. Garmin bietet selbst haufenweise kommerzielle Karten an. Bevor ich mir die zulege, habe ich mir die Open Street Map (OSM) Karten angeschaut und die funktionieren bis dato wunderbar und ich glaube nicht, dass ich mir noch eine orginal Garmin Karte holen werde. Ausprobiert habe ich bis dato die Karten:
- Radkarte Deutschland
- Radkarte Europa
- Topographische Karte Deutschland
Es werden noch wesentlich mehr Karten speziell für Garmin Geräte angeboten. Die Karten bieten teilweise eine direkte Integration in MapSource. Über MapSource lassen sich Routen, Tracks, Waypoints erstellen und die Daten sowie die Karten auf das Garmin laden. Sind die Karten erstmals auf dem Gerät lassen sich auch andere Webseiten benutzen um Routen etc. zu erzeugen, herunterladen und anschließend auf das Gerät laden. Gute Seiten die ich bis dato gefunden habe sind:
Weitere Links:
- Blog zum 705: http://garminedge.wordpress.com/
- Erworben bei: http://www.amazon.de
- Schutzfolie erworben bei: http://www.amazon.de
Bilder:
Routing (Folge der Linie)
Bitte Abbiegen
Satelliten Empfang im Haus