[Allegro] Himmelfahrt steht vor der Tuer

[Bernhard Eversberg]

An Himmelfahrt, da soll dies Jahr aber mal so richtig eine ruhige
Kugel geschoben werden. Nach dem Prinzip der Vorfristigkeit wurden ja
zum Aschermittwoch schon mal die Verbesserungen an avanti durchgepaukt,
um die UPDATE-Ablösung damit zu perfektionieren. Zwischendurch zum 1.4.
wurde das FreiRaum-Paket ausgeheckt. Nun kommt, prae festum, noch
ne Schippe drauf: die Loslösung von a30 aus der Sprachabhängigkeit.
An sich wäre sowieso Pfingsten dafür das angemessene Datum gewesen...
(Ja ok, "prae festo" muß es heißen, aber wer weiß schon noch, daß mit
prae, anders als mit post, der Ablativ zu stehen hat? Für eine
lateinische Version regte sich denn auch bislang keine Nachfrage.)

Das alte a99 hat(te) dem neuen a30 neben so manchem anderen ein
wichtiges Feature voraus: die UIF-Dateien. Wir mußten danach trachten,
auch in a30 die Beschriftungen und Tooltips der Oberflächenelemente
konfigurierbar zu machen. a30 soll ja gerade in seiner Wandelbarkeit
an der Oberfläche alle alten Programme ein gutes Stück hinter sich
lassen.

Abermals wurde die Strategie der denkbarsten Einfachheit gewählt, um
zu einer Lösung zu gelangen. Toll wäre natürlich was mit XML/XSLT,
ganz toll wäre eine "Lokalisierbarkeit" nach dem Verfahren der
kommerziellen Windows-Applikationen, doch "denkbar einfach" sind diese
Rezepte nicht. 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 (in 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.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.

-----------------------------------------------------------------------

Das Paket wurde aktualisiert, die Fortbildung auch (Kap.19):

   http://ftp.allegro-c.de/aktuelle-version/a30.zip