TassKaff Umgang mit Beispieldaten


Eine ergonomische Oberfläche zu entwerfen ist der eine Teil der Arbeit.

Die Spezifikation wird dann erst richtig rund, wenn der Kunde "seine" Daten in der Anwendung vorfindet.

Combo- und Listboxen

Bei einer Präsentation machen sich leere Comboboxen nicht gut; in einem ersten Schritt können denkbare Werte innerhalb der Spezifikation einfach aufgezählt werden:

<Combo label="Anrede:" Items="Frau|Herrn|Firma" />

Wird das Attribut "Anrede" mehrfach auf verschiedenen Masken benötigt, wird es bald lästig diese redundanten Daten zu pflegen.

Sinnvoller ist es, die Wertevorräte in einer Textdatei zu speichern, und diese den jeweiligen Komponenten zuzuweisen. Dann können diese Wertelisten auch geändert werden, ohne die die GUI-Spezifikation angefaßt werden muß.

In diesen Textdateien werden die gewünschten Einträge einfach zeilenweise untereinander erfaßt. Eine Leerzeile bewirkt auch in der Combobox einen leeren Eintrag.

Zur Pflege dieser Daten kann ein normaler Texteditor eingesetzt werden; auch der Editor des GuiBuilders kann dazu "mißbraucht" werden.

Beispiel:

Die eingegebenen Daten werden hier in die Datei "Anrede.lst" gespeichert.

Um auf diese Daten zuzugreifen, wird bei Combo- und Listboxen das Attribut file=<Dateiname> verwendet; für unser Beispiel also

<Combo label="Anrede:" file="Anrede.lst" />

Das Ergebnis sieht dann etwa so aus:

Da es in einem Softwareprojekt u.U. sehr viele solcher Wertevorräte gibt, überlassen faule GUI-Designer die Pflege dieser Daten der Fachabteilung des Kunden. ;-)

Tabelle

Ähnlich wie bei den Comboboxen können auch Tabellen mit Daten aus einer Textdatei gefüllt werden. Hierzu dient das Attribut val="MyData.txt".

In der Textdatei müssen die Werte zeilenweise eingetragen werden, wobei die Spalten mit | getrennt werden. Der Einfachheit halber können Sie auch hier den GuiBuilder als Editor einsetzen.

In der Oberfläche sieht das dann so aus:

Beispieldaten in XML-Dokumenten

Wenn die Gestaltung der Oberfläche weitgehend abgeschlossen ist, werden für Präsentationen oder für die Dokumentation Beispieldaten benötigt.

Nun kann man diese Daten natürlich immer wieder aufs neue in der Oberfläche eingeben, aber die Dokumentation eines Anwendungsfalls über mehrere Masken kann sich doch als recht umständlich erweisen.

Der einfache Trick besteht nun darin, daß die in der Oberfläche eingegeben Daten zur späteren Wiederverwendung in einem XML-Dokument gespeichert werden. Der GuiBuilder wird also quasi als XML-Editor eingesetzt.

Hierzu dienen die eingebauten Methoden XmlSave() und XmlOpen(). Diese können z.B. in einem (Popup)Menü oder in der Toolbar "versteckt" werden.

Über XmlSave() wird ein Datei-speichern-Dialog aufgerufen, der die Daten aus der Oberfläche in einem XML-Dokument speichert; der Name dieses Dokumentes ist anzugeben.

Mit XmlOpen() wird ein Datei-öffnen-Dialog aufgerufen, mit dem man sich die gewünschten Datei aussuchen kann.

Im Verzeichnis "lib/tutorial" findet sich eine Spezifikation "AdressBeispiel.xml" hier sind die erwähnten Methoden in der Toolbar untergebracht. Zusätzlich können hier mit dem Button "neu" die Eingaben komplett gelöscht werden. Die Tabellen verfügen über Methoden zum Einfügen und Löschen von Zeilen.

Über den Button "öffnen" kann z.B. die Datei "AdressDaten.xml" geöffnet und damit ihr Inhalt in die Oberfläche geladen werden.

Das so erstellte XML-Dokument kann einem Formular oder Dialog als Default-Wert mit dem Attribut file="MyData.xml" zugewiesen werden. Dann werden diese Daten mit Anzeigen des Fensters automatisch geladen.

Ansicht der Daten in der Oberfläche:

Gespeicherte Daten im XML-Dokument:

Risiken und Nebenwirkungen

Voraussetzung für das Speichern von Daten in einem XML-Dokument ist, daß alle Komponeten einen eindeutigen Namen haben.

Bei dem Einsatz von Registerkarten müssen die Komponenten je Karte einen eindeutigen Namen haben.

Im einfachsten Fall wird das Label der Komponente als Name verwendet; hierbei werden automatisch etwaige Sonderzeichen weggelassen oder konvertiert. Ein sauberes Vorgehen besteht aber darin, die Komponenten explizit mit dem Attribut "name=<ComponentName>" einen Namen zuzuweisen; dieses hat auch den Vorteil, daß Änderungen am Label nicht auf den Namen der Komponente "durchschlagen".

Wichtig!

Wenn sich zwischen dem Speichern von Beispieldaten und dem späteren Laden Änderungen an der Spezifikation ergeben haben, kann es naturgemäß zu Fehlern kommen; insbesonders dann, wenn sich der Name einer Komponente geändert hat, oder sie gelöscht wurde.

Diese Änderungen können natürlich "zu Fuß" in den XML-Dokumenten nachgeführt werden. Aber um sich diese umständlich Arbeit zu ersparen sollte die Speicherung von Beispieldaten in XML besser erst dann erfolgen, wenn die Spezifikation weitgehend stabil ist.

Die Dateinamen der XML-Dokument müssen nach klaren Regeln vergeben werden, denn die Daten einer Adresse passen naturgemäß nicht zu der Oberfläche, die einen Auftrag darstellt. Am klarsten ist die Regel, dem Dateinamen der GUI-Spezifikation um die Zeichenfolge "Daten" zu ergänzen, und diese für mehrere Sätze von Beispieldaten zu nummerieren. Wenn also "Adresse.xml" die GUI-Spezifikation enthält, dann heißen die Beispieldaten hierzu "AdressDaten1.xml", "AdressDaten2.xml" usf.

Seitenanfang