08.12.2012 Aufrufe

2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...

2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...

2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

gewissen Grad an Abstraktion aufweisen muss. Die Informationen, nach denen wir jetzt<br />

suchen, beziehen sich aber gerade auf einen solchen Einzelfall, sind also zu speziell, um in<br />

das allgemeine Pattern aufgenommen zu werden.<br />

Also muss ein Blick auf den relevanten Ausschnitt des Präsentationsmodells Klarheit<br />

verschaffen. Die Tatsache, dass sich direkt unter dem Input-Element für die Jahreseingabe ein<br />

Text-Element vom Typ YearValidationResult befindet, legt nahe, dass das<br />

Validierungsresultat dort in textueller Form angezeigt werden soll. Ebenfalls plausibel<br />

erscheint es anzunehmen, dass der Validierungsmechanismus überprüfen soll, ob die Eingabe<br />

eine gültige Jahreszahl, d.h. eine ganze Zahl ist. Doch ob eine Eingabe verpflichtend ist, d.h.<br />

auch ein leerer Wert des Feldes als gültige Eingabe gewertet werden soll, kann aus dem<br />

Präsentationsmodell nicht erschlossen werden. Schließlich muss sich der Entwickler zur<br />

Beantwortung von Frage 1 ebenfalls auf Plausibilitätsüberlegungen verlegen. Seine Erfahrung<br />

wird ihm vermutlich sagen, dass Live-Validierungen üblicherweise durch ein blur-Ereignis<br />

ausgelöst werden, d.h. wenn das zu überprüfende Eingabefeld den Fokus verliert. Und in<br />

Abwesenheit von Hinweisen, die einen anderen Trigger-Mechanismus nahelegen, wird er sich<br />

bei der Implementierung höchstwahrscheinlich für diese Variante entscheiden.<br />

Was hat die Diskussion dieses kleinen Szenarios erbracht? Es ist deutlich geworden, dass,<br />

falls sich die Modellierung eines RIA-Features tatsächlich auf die Markierung eines<br />

Präsentationselements durch einen Tagged Value und die Angabe des entsprechenden Pattern-<br />

Automaten beschränkt, dem Entwickler nichts anderes übrig bleibt, als im<br />

Präsentationsmodell nach Implementierungshinweisen zu suchen. Und ebenfalls hat sich<br />

gezeigt, dass, falls er wirklich sichere und klare Anweisungen wünscht, er diese dort in nur<br />

sehr begrenztem Maße finden wird.<br />

Immerhin konnten in diesem Beispiel bestimmte Informationen, z.B. über den<br />

Validierungsmechanismus, gewissermaßen aus dem Kontext erschlossen oder erraten werden.<br />

Folgendes Beispiel soll zeigen, dass das nicht immer möglich ist.<br />

Beispiel 2<br />

Das <strong>Web</strong>formular zum Erzeugen einer neuen Publikation im PVS soll dem Benutzer u.a. die<br />

Möglichkeit zur Angabe von Schlüssel-Wert-Paaren (BibTeX-Tags) bieten, mit denen eine<br />

Publikation zusätzlich (zu ihren fest vorgegebenen Attributen) charakterisiert werden kann.<br />

Sowohl das Eingabefeld für den Schlüssel als auch für den Wert eines solchen Tags soll mit<br />

einem Live-Validierungsmechanismus versehen werden. Das Validierungsresultat soll wieder<br />

als kurzer Text unter dem jeweiligen Eingabefeld angezeigt werden. Damit kann der<br />

entsprechende Ausschnitt aus dem Formular folgendermaßen modelliert werden:<br />

Abbildung 22: Tageingabe im Publikationsformular (Ausschnitt)<br />

49

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!