Seite4192

• 4.2.3.2 Umgang mit den Datentypen
  • Allgemeines
  • Mapping vom Ecore- zu Java-Datentypen
  • Auswahl des Sichtelements
  • Validatoren und (De-)Formatierer
  • Übersichtstabelle

4.2.3.2 Umgang mit den Datentypen

Allgemeines

Im Folgenden sollen die Datentypen und ihre Verwendung in der zu generierenden Anwendung (und dadurch in den Templates) Betrachtungsgegenstand sein. Diese Betrachtung ist Schichten übergreifend und wird an den jeweiligen Stellen im Wiki auch aufgegriffen werden, dieses Kapitel soll aber zentraler Anlaufpunkt für die Behandlung dieses Gesichtspunkts sein.

Mapping vom Ecore- zu Java-Datentypen

Ausgehend vom im Ecore-Modell verwendeten Datentypen für ein Attribut, müssen im JavaBean der richtige Java-Typ zugeordnet werden. Die meisten Datentypen können 1-zu-1 abgebildet werden. Einigen Datentypen ist zwar ein Datentyp aus dem EMF-Packet zugedacht, wie z.B. der EEList, sie können aber per Definition passenden Java-Typen zugeordnet werden. Im Fall der EEList wäre dies java.util.List. Andere Datentypen sind rein EMF-spezifischen und auch nur für den Einsatz in diesem Kontext gedacht und werden deshalb nicht unterstützt.
Von der Unterstützung bestimmter Datentypen, die zwar rein theoretisch in Java abbildbar wären, wird ebenfalls abgesehen, da der ihrer Umgang mit ihnen uns zu komplex ist. Auch auf die Unterstützung primitiver Datentypen wird verzichtet. Die im Modell verwendeten primitiven Datentypen werden daher nicht auf die entsprechenden primitiven Datentypen in Java sondern auf die Java-Klasse des Datentyps gemappt (Beispiel: EInt wird nicht zu int sondern zu Integer, also dass gleiche Mapping-Ergebnis wie bei EIntegerObject).
Bei dem Datentypen Date ist zu beachten, dass eine Unterscheidung zwischen Zeit und Datum möglich ist. Die ist sinnvoll, wenn die Zeit ohne das Datum oder das Datum ohne die Zeit erfasst werden soll. Dieser Umstand müsste am Modell annotiert werden. One Annotation wird bei uns unterstellt, dass nur das Datum (also ohne Zeit) erwünscht ist.
Bei der Abbildung von Zu-N-Relationen wird per Definition im Programmcode der Datentyp java.util.Set verwendet, also ein Menge eindeutiger unsortierter Objekte.

Auswahl des Sichtelements

In den meisten Fällen ist das einzeilige Textfeld das geeignete Sichtelement (Widget) für Eingabe und Darstellung des Attributs. Für einige Datentypen sollten allerdings andere GUI-Komponenten gewählt werden. Für den einfachen True/False-Wertebereich des Boolean-Datentyps ist eine Checkbox das Mittel der Wahl, die Datumsauswahl geschieht über die Kombination von Textfeld und daneben stehenden Button, mit dem die Kalenderfunktion aufgerufen wird. Für eine Liste kommt die Kombination von Textfeld, Hinzufügen- und Enfernen-Button und Listen- bzw. ComboBox-Komponente in Frage, je nachdem wieviel Platz zur Verfügung steht und/oder ob Mehrfachauswahl erlaubt ist. Enumerationstypen lassen sich bei kleiner Anzahl von Werten als Liste gruppierter Radio-Buttons (bei Einfachauswahl) oder als Liste von gruppierten Checkboxen darstellen. Bei Mehrfachauswahl wäre die Darstellung als zwei Listen vorstellbar, bei der die linke Liste als Pool der verfügbaren Elemente fungiert und mit Hinzufügen- und Enfernenbzw.oder aus ihr entfernt würde. Die Komplexität der Behandlung von Enumeration und Liste hat dazu geführt, dass diese beiden Datentypen nicht unterstützt werden. Der Map-Datentyp wird ebenfalls nicht unterstützt, da sich eine ähnliche Komplexität bei der Zuweisung von Schlüssel und Wert ergibt. Mit einer Map könnte ein ganzes Formular ausgedrückt werden.

Eine Besonderheit ergibt sich für den häufigen Datentyp String. Es wäre vorstellbar, dass ein String-Attribut mit einem ganzen Text-Abschnitt belegt werden soll. Für diesen Fall müsste statt eines einzeiligen ein mehrzeiliges Textfeld verwendet werden. Die Entscheidung welches der beiden Sichtelemente zum Einsatz kommen soll, könnte man über die im Modell definierte maximal erlaubte Länge des Strings abhängig machen. Alternativ könnte man die Entscheidung auch explizit dem Modellierer überlassen, der das Attribut dann mit einer entsprechenden Annotation versehen muss. Zunächst soll nur die Variante 1 unterstützt werden. Da alle Textfelder unabhängig vom Datentyp aus ergonomischen Gründen die Gleiche Länge haben sollen, werden bei String-Attributen, für die eine höhere maximale Anzahl an Zeichen zulässig ist, als im Textfeld ohne scrollen anzeigbar wären, an Stelle des einzeiligen Textfeldes und mehrzeiliges verwendet.

Validatoren und (De-)Formatierer

Validatoren und Formatierer arbeiten in den meisten Fällen Hand in Hand, so dass sie hier gemeinsam behandelt werden sollen. Oft wäre eine getrennte Betrachtung gar nicht möglich, da der eine Verarbeitungsschritt vom Ergebnis des anderen abhängt.
Es sind zwei Wege zu betrachten. Beim Weg vom Datenmodell in die Darstellung muss der Wert des Attributs bei einigen Datentypen auf Grund der Beschaffenheit des Sichtelements aber auch aus semantischen Gründen aufbereitet werden, sprich formatiert werden. Beim Zurücklesen des Wertes von Darstellung ins Datenmodell müssen einerseits die Formatierungen zurückgenommen als auch die Konformanz des Wertes zu seinem Datentyp, sofern die nicht von der Art des Sichtelements sichergestellt werden kann, überprüft wird.
Für den letzteren Prozess, also das Zurücklesen des Werts in das Datenmodell, müssen Deformatierer und Validatoren geeignet kombiniert in Reihe geschaltet werden. Bevor ein Wert deformatiert werden kann, muss zunächst sicher gestellt werden, ob der Zustand des Werts dies überhaupt zulässt. Validitatoren müssen also z.B. prüfen, ob der Wert die ausreichende Länge hat. Ein Typische Deformatierung wäre das Ersetzen des Kommas bei einer Zahl durch den Punkt. (Wenn die Lokalisierung ein Komma bei der Darstellung vorsieht). Zum Deformatieren gehört ebenfalls das Zurückcasten des gegebenen Werts als String in seinen ursprünglichen Typ. Der Vorgang des Castens ist in diesem Sinne bereits eine Überprüfung der Korrektheit des gegebenen Wertes. Auch wenn das Casten erfolgreich war, können immer noch semantische Prüfungen erforderlich sein. Diese werden dann allerdings in der Geschöftslogik der Serverseite durchgeführt, da unter Umständen auch Zusammenhängen mit anderen Daten auf Zulässigkeit überprüft werden müssen.

Übersichtstabelle

Ecore Datentyp	Java Datentyp	Sichtelement	Validator	Formatter	von uns unterstützt
EBigDecimal	java.math.BigDecimal	einzeiliges Textfeld	NumberValidator	DecimalFormat	nein
EBigInteger	java.math.BigInteger	einzeiliges Textfeld	NumberValidator	-	nein
EBoolean	Boolean	Checkbox	-	-	ja
EBooleanObject	Boolean	Checkbox	-	-	ja
EByte	Byte	einzeiliges Textfeld	NumberValidator	-	ja
EByteArray	byte[]	einzeiliges Textfeld	-	-	nein
EByteObject	Byte	einzeiliges Textfeld	NumberValidator	-	ja
EChar	Character	einzeiliges Textfeld	-	-	nein
ECharacterObject	Character	einzeiliges Textfeld	-	-	nein
EDate	java.util.Date	einzeiliges Textfeld mit Button	DateValidator	DateFormat	ja
EDiagnosticChain	-	-	-	-	nein
EDouble	Double	einzeiliges Textfeld	NumberValidator	DecimalFormat	ja
EDoubleObject	Double	einzeiliges Textfeld	NumberValidator	DecimalFormat	ja
EEList	java.util.List	ComboBox, List	-	-	nein
EEnumerator	java.util.Enumeration	Radio Buttons, Checkboxes, ComboBox, List	-	-	nein
EFeatureMap	-	-	-	-	nein
EFeatureMapEntry	-	-	-	-	nein
EFloat	Float	einzeiliges Textfeld	NumberValidator	DecimalFormatter	ja
EFloatObject	Float	einzeiliges Textfeld	NumberValidator	DecimalFormatter	ja
EInt	Integer	einzeiliges Textfeld	NumberValidator	-	ja
EIntegerObject	Integer	einzeiliges Textfeld	NumberValidator	-	ja
EJavaClass	Class	-	-	-	nein
EJavaObject	Object	-	-	-	nein
ELong	Long	einzeiliges Textfeld	NumberValidator	-	ja
ELongObject	Long	einzeiliges Textfeld	NumberValidator	-	ja
EMap	java.util.Map	Formular	diverse	diverse	nein
EResource	-	-	-	-	nein
EResourceSet	-	-	-	-	nein
EShort	Short	einzeiliges Textfeld	NumberValidator	-	ja
EShortObject	Short	einzeiliges Textfeld	NumberValidator	-	ja
EString	String	ein-/mehrzeiliges Textfeld	Längenvalidator (optional)	-	ja
ETreeIterator	java.util.Iterator	-	-	-	nein

Bei uns werden primitive Ecore-Datentypen (also z.B. ELong, EInt) nicht auf die entsprechenden primitiven Java-Datentypen (also im Beispiel long und int) sondern auf die Java-Klassen dieser Datentypen also Long und Integer. Dies entspricht somit dem gleichen Mapping-Ergebnis von ELongObject bzw. EIntegerObject.

---

weiter zu 4.2.3.3 Templatierung der Entitäten
zurück zu 4.2.3.1 Allgemeines
zurück zu 4.2.3 Templatierung der Persistenzschicht
zurück zu 4.2 Implementierung des Generators
zurück zu 4 Implementierung
zurück zu [FrontPage]