[Allegro] a30: Mehrfachfelder in Formularen etc.

Mo Apr 12 15:39:18 CEST 2010

a30-Quelldateien und alles andere liegen neu bereit:
   http://ftp.allegro-c.de/aktuelle-version/a30.zip

Verbessert und erweitert, die FreiRaum-Anleitung:
   http://www.allegro-c.de/doku/a30/frr.htm
Jetzt im Anhang mit Illustrationen, genau zeigend, wie man diverse
Formularelemente notiert und wie sie dann aussehen. Neu ist, daß man
statt "Button" auch "Image" verwenden kann, mit eigenen Bildchen (.png,
.gif und .jpg), die genau wie ein Button funktionieren:

Image fragezeichen.jpg|help
startet bei Klick auf das jpg-Bild den job  help.job.

Hier nur noch, wie die Behandlung von Mehrfachfeldern nun auf
einfachstmögliche Weise gelöst ist.

           Nachklapp zur InnovationsInitiative 2010
           ----------------------------------------

21. Mehrfachfelder. Mit das unbequemste Thema bei Bibliotheksdaten!

Mehrfachinhalte können in drei Situationen auftreten:
a) Mehrere gleichwertige Angaben innerhalb eines Felds,
    z.B. #31 Schlagwort1; Schlagwort2; Schlagwort3
    Das ist unproblematisch: Für die Formulartechnik ist das nur *ein*
    Datenfeld!

b) Echte Feldwiederholung
    Mehrfaches Auftreten eines Feldes, wobei die einzelnen Exemplare
    gleichwertig sind, z.B.
    #31 Schlagwort1
    #312Schlagwort2
    #313Schlagwort3
    Typischerweise hat dabei das erste Feld kein Wiederholungszeichen
    (besser gesagt, auf der Position steht ein Leerzeichen)

c) Scheinbare Feldwiederholung
    Mehrfaches Auftreten derselben Feldnummer mit inhaltlich jeweils
    anderer Bedeutung, z.B.
    #33B britisches Schlagwort
    #33L LC-Schlagwort
    In solchen Fällen ist oft, aber nicht immer, das Feld mit dem
    Leerzeichen hinter der Feldnummer ungebräuchlich, und die Mehrfach-
    zeichen sind Buchstaben, keine Ziffern.

Man *kann* natürlich mehrere Felder im Formular vorsehen, z.B. also in
einer .frl-Datei schreiben:

#31
#312
#313

bzw.

#33B
#33L

aber erstens wird dadurch das Formular u.U. unhandlich lang und
zweitens kann es im Fall b) auch derartig viele Mehrfachfelder geben,
daß es äußerst unpraktisch und unelegant würde.

Also muß eine Lösung her, die Platz spart, die Fälle a) und b)
in gleicher Weise abdeckt und einfachstmöglich einzurichten ist.
Hier ist sie:

#31.
++

bzw.

#33.
++

Das ist alles! Eine kürzere Idee hatte keiner, also wurde sie genommen.

Das ++ hat zur Folge, daß hinter dem Eingabefeld für die erste #31
bzw. #33 (freiraum.job findet selber raus, welches Feld das erste ist)
ein kleiner Button erscheint mit der Aufschrift ++. Betätigt man den,
erscheint ein eigenes Fensterchen mit einem großen Eingabefeld, darin
die weiteren im Satz existierenden Felder, jedes mit seiner Kategorie-
nummer vorweg(!). Hier muß dann der Bearbeiter ein wenig Sachkenntnis
besitzen, um damit korrekt umzugehen - aber jede andere Lösung wäre
ungleich aufwendiger.
Das Mehrfachfenster wird mit einem eigenen Button wieder geschlossen
oder mit Esc verlassen - dann bleiben die Änderungen unwirksam.

Tip: Statt mit der Maus den Button ++ oder den Button "Eingabe" im
Sonderfenster zu betätigen, kann man auch mit Tab-Taste zuerst den
Button aktivieren (sein Rand wird dann bläulich) und die Leertaste (!)
drücken. Das gilt auch für andere Buttons in a30.

Um's genauer zu sagen:
Die gezeigte Syntax gilt für die Notation in einer .frl-Datei. Eine
solche Datei wird mit dem Universalskript  freiraum.job  in einen
Datenstrom für a30 verwandelt, dabei entsteht dann aus dem ++ alles,
was dem Programm im konkreten Fall übergeben werden muß.
Will man statt dessen den Datenstrom in einem Job selber erzeugen,
wäre das so zu schreiben:

wri "_!_SET FRE FreiRaum"
wri "_!_FRE "
wri "TE <b>Schlagwort</b>|80"
wri "IN V31.|400"
wri "DA " #31.
wri "++"
wri "DA " #31p
wri "DA " #31s
wri "--"
wri "TE <b>Fremd-SW</b>|80"
wri "IN V30.|400"
wri "DA " #33B
wri "++"
wri "DA " #30L

Man wird zugeben: dies sieht weniger toll aus. Außerdem wird hier
nicht dem Fakt Rechnung getragen, daß ja auch noch mehr Sachen
unter #31 sein können, bzw. das eine oder andere gar nicht besetzt
ist.
Der Job  freiraum.job  produziert ein solches Skript automatisch,
berücksichtigt dabei aber alle vorkommenden Mehrfachfelder.

Trick: Unsichtbare Variablen
----------------------------
In HTML-Formularen kann man bekanntlich unsichtbare Eingabefelder
unterbringen, deren Inhalt gleichwohl beim Absenden mitgeliefert
werden. Das ist äußerst nützlich und davon wird ausgiebig Gebrauch
gemacht, z.B. für Default-Werte, die der Nutzer nicht ändern oder
auch gar nicht sehen soll, oder für zusätzliche Flags und dergl.,
die bei Rücksendung des Formulars der aufzurufende Job erhalten soll.
Mit dem FreiRaum-Formular geht das so:

#nnn 1
data abc
Button aufschrift|jobname

Die Variable #nnn erhält ein Eingabefeld der Länge 1 Pixel, das ist
dann unsichtbar, enthält aber "abc" als Inhalt.
Auf dem Button steht "aufschrift", beim Klick wird der Inhalt des
Formulars an den Job jobname.job gesandt, darunter auch Vnnn mit
dem Inhalt "abc". nnn kann auch eine u-Variable sein.

+----------------+
| Summa summarum |
+----------------+
Die Arbeit mit einer textbasierten Anwendung ist immer ein "Dialog"
(die Fragwürdigkeit dieser Metapher nehmen wir jetzt mal hin), bei
dem der Anwender Eingaben zu tätigen und "Fragen" zu "beantworten"
hat, woraufhin das Anwendungsprogramm in mehr oder weniger plausibler
Weise reagiert und vom Nutzer weitere Angaben "anfordert". Der Nutzer
sieht sich stets mit etwas konfrontiert, das im weitesten Sinne als
"Formular" bezeichnet werden kann. Das kleinste denkbare Formular ist
die simple Mitteilung, die er nur per Tastendruck quittieren muß,
damit's weitergeht, dann kommt die Ja/Nein-Entscheidung, und es geht
bis hin zum umfänglichen Erfassungsformular für einen hochkomplexen
Datensatz mit etlichen Eingabeinstrumenten für unterschiedliche
Datentypen. Das Programm wird von einer Nutzereingabe stets zu
irgendeiner Aktion veranlaßt, wobei meistens auf die eine oder andere
Datenbasis zugegriffen wird, lesend oder auch schreibend.
Dieses gesamte Szenario kann mittels der neuen Formulartechnik
"FreiRaum" nun mit a30 ausgestaltet und die Anforderungen mit Hilfe
der serverseitigen Skriptsprache FLEX abgedeckt werden. Damit wird a30
zu einem Medium für das ganze Spektrum denkbarer Aufgaben, die
bei der Arbeit mit Bibliotheksdaten zu bewältigen sind. Erstmals ist
a30 ein plattformunabhängiges Programm, zu dessen Nutzung auf der
Seite des Endnutzers (Bibliothekar oder Leser) nur ein beliebiger,
nicht zu alter Browser notwendig ist.
Programmiertechnisch beruht das Ganze neben dem Adobe-Flex-Programm
a30.swf auf wenigen universellen PHP-Skripten und .job-Dateien, die man
unverändert in jede Anwendungsumgebung übernehmen kann. Serverseitig
werden die in C++ erstellten Programme avanti und acon eingesetzt.

Alle anwendungspezifischen Prozeduren werden, wie schon erwähnt, in der
allegro-eigenen Skriptsprache FLEX  programmiert, die man für die
Datenbankzugriffe eh und je braucht. PHP oder Perl, Javascript oder XML
oder sonstige externe Komponenten werden zur Gestaltung und
Konfigurierung von Anwendungen nicht gebraucht. Gegenüber allen
bisherigen Web-basierten allegro-Anwendungen ist das eine drastische
Vereinfachung.
Ambitionierte Anwender können gleichwohl an allen Stellen mit eigenen
Erweiterungen oder Modifikationen ansetzen: bei dem frei verfügbaren
Programm a30 selbst, mit PHP oder Perl auf der Serverseite und mit
JavaScript auf Clientseite. Damit ist a30 zugleich die Plattform mit
dem größten Ausmaß an Offenheit für das Arbeiten mit allegro.

B.Eversberg