a30-Fortbildung
|
19. Konfigurierung der sprachlichen Elemente an der Oberfläche Nachdem sich die Methodik des strukturierten Datenstroms nun schon für das neue FreiRaum-Konzept der konfigurierbaren Formulare bewährt hat, drängte sich der Gedanke auf, auch das Oberflächenvokabular in diesem Kontext abzuhandeln, statt dafür schon wieder was eigenes aus dem Hut zu zaubern. Die Lösung sieht so aus: o Ein neues Symbol _!_UIF im Datenstrom leitet einen Abschnitt ein, in dem Zuordnungen von Texten zu Oberflächenelementen stehen. o Die Elemente haben eindeutige Namen, nicht (wie bei allen alten Programmen) Nummern. Das sind ihre "id"-Attribute im Flex-Quellcode. o Um einem Element namens XYZ eine Beschriftung und einen Tooltip zuzuordnen, schreibt man eine Zeile mit dieser Syntax (UTF-8!): XYZ | Beschriftung | Text für Tooltip Beispiel: bFORnew | Neusatz | Als neuen Datensatz speichern o Ist es ein Element ohne Beschriftung (Image oder Button mit Grafik) oder Eingabefeld, dann so: XYZ | - | Text für Tooltip Beispiel: iEnde | - | Dieses Fenster zumachen o Ein Tooltip kann mehrzeilig sein; dann ist der gesamte Text hinter- einander zu schreiben, Zeilenwechsel mit _ angedeutet. o Beidseits des Trennzeichens | können beliebig viele Spatien stehen (oder gar keins), nicht jedoch Tabs o Mit der Zeile KURZLISTE leitet man einen zweiten Abschnitt ein, der sich auf die Elemente des Kurzlistenfensters bezieht. (Wenn weitere Unterfenster hinzukommen, kann das entsprechend eingerichtet werden.) o Alle bisher verwendeten textlichen Teile der Oberfläche bleiben als Defaults erhalten; wer nur partielle Änderungen an der deutschen Oberfläche will, braucht also nur die wirklich zu ändernden Elemente anzugeben, normalerweise innerhalb eines Jobs, z.B. im _start.job o Ein _!_UIF-Abschnitt kann in jedem Job vorkommen, nicht nur im _start.job! D.h. es sind dynamische, partielle Änderungen der Oberflächenbeschriftung während einer Sitzung machbar. o Kommentarzeilen können, mit // beginnend, beliebig eingestreut werden, aber keine Kommentare am Ende einer Zeile! o Zuordnung anderer Grafiken (viele sind's ja nicht!) ist vorerst nicht möglich, es soll aber dann so sein, daß anstelle des '-' der Name der Grafikdatei anzugeben ist. o Nicht einbezogen ist das Menü rechts oben im Hauptfeld! Dieses ist ja bereits flexibilisiert und es liegt ihm eine schlichte XML-Struktur zugrunde (weil das intern in Adobe Flex so vorgesehen ist). Man liest ein anderes Menü ein unter der Kennung _!_BAR, siehe a30-Fortbildung Kapitel 5. Eine Menüstruktur kann man daher unter dem Label _!_BAR ebenfalls in den _start.job einhängen. o Menütexte unter dem "Menu"-Tab und der Inhalt unter "FreiRaum" sind ebenfalls nicht unter _!_UIF zu erledigen! Dazu gibt es ja bereits entsprechende andere Möglichkeiten, s. Kap. 14 und 18. Am einfachsten kann man so vorgehen, daß man sich eine Datei uif-en.txt macht und sie auf das DbDir (!) legt. Im _start.job schreibt man: var "F" D "uif-en.txt" wri um diese Datei einzubinden. [acon kann sie nur auf DbDir finden] Hier kann man sich die Wirkung an einem Beispiel anschauen: http://www.biblio.tu-bs.de/db/a30/neutral.htm Dann unter dem "Menu"-Tab auf "Deutsch" klicken. Auch die GND-Bank werden wir entsprechend aufbessern, sie wird in Kürze erneuert. Selektive Änderungen während der Laufzeit kann man z.B. mit write- Befehlen innerhalb eines Jobs machen. Beispiel: write "_!_UIF " n write "bBrief | Erg.Menge | Zeigt die Ergebnismengenliste" n Damit würde man schnell mal eben die Beschriftung und den Tooltip des "Kurzliste"-Buttons ändern (sein interner Name ist "bBrief"). Wir stellen zwei komplette uif-Dateien bereit: uif.txt mit den deutschen, uif-en.txt mit englischen Bezeichnungen, darin stehen jeweils auch unter _!_BAR die Menüversionen. Die Datei uif.txt dient als Vorlage zum Erstellen einer eigenen Datei z.B. für eine andere Sprache oder eine nach eigenem Geschmack eingerichtete Variante; man braucht sie ansonsten nicht, weil die Defaults schon im Programm drinstecken, In den genannten Dateien sieht man die Namen der Elemente, Sie sind so angeordnet, daß sie der Reihenfolge im Haupt- bzw. Kurzlisten- fenster von links oben nach rechts unten entsprechen, doch ist dies keine Bedingung! Und was man nicht ändern will, darf fehlen. (Die Elementnamen beginnen mit b, l oder i, wenn es sich um Buttons, Labels (Textfelder) oder Images (Icons) handelt; das aber nur der besseren Übersichtlichkeit wegen, programmlogisch ist das unerheblich.) Pfiffigen Experten wird nicht entgehen, daß mit der neuen (Los-)Lösung das a30-Rahmenwerk ein höheres Potential zum Einsatz in ganz anderen Zusammenhängen gewinnt, gänzlich losgelöst von allegro. Denn von woher a30 seinen Datenstrom erhält und wie er erzeugt wurde, das ist ihm ja egal: Die Trennung von Datenbank und RIA, von Server und Client, war von Anfang an 100%. Setzt man a30 für ganz andere Zwecke ein, braucht man auch acon und avanti-FLEX nicht, sondern man erzeugt die Datenströme mit ganz beliebigen eigenen Mitteln, ohne vorher mit dem Adobe-System den a30-Quellcode irgendwie ändern zu müssen. Die Notwen- digkeit zum Eingriff in diesen wurde jetzt nur nochmals verringert. |