[Allegro] ZAboM Lektion 2: Neuer Band

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg, liebe Liste,

|> In der Bibliothek, an die ich gerade denke, wird die Zugangsnummer
|> aber beim Rechnungseingang, also lange vor dem ersten Hefteingang
|> vergeben.
|>
| Es kann wohl nicht erwartet werden, daß jeder seine
| Geschäftsgangs-Usancen unverändert beibehalten kann, dafür sind sie
| denn doch von einer Bibliothek zur nächsten zu verschieden.

Es kann aber auch nicht erwartet werden, dass jemand seinen
Geschaeftsgang quasi unbesehen auf das undokumentierte
Geschaeftsgangsmodell von ZAboM umstrickt.

Eigentlich ist es ja so, dass ein vernuenftiges Datenmodell
die Basis fuer viele individuelle Geschaeftsgangsloesungen
sein kann. Aufgabe von "allegro" waere es, durch Indexierung
und Abfragemasken etc. einerseits das Zusammenspiel der Daten zu
gewaehrleisten, andererseits aber auf einer anderen Ebene
den Geschaeftsgang (anzubietende bzw. zu ueberspringende Abfragen,
Reihenfolge, ...) abzubilden.

Man braucht dafuer vermutlich kein GGDL (GeschaeftsGang Documentation
Language), aber vermutlich doch etwas clevereres als etwa die
alte UIFOGER anbot (man wollte immer noch mehr stilllegen, als
dort angeboten wurde, weil alles so umstaendlich war).

Denkbar waeren z.B. stark modularisierte Flexe, die sich nicht
fest einprogrammiert gegenseitig aufrufen, sondern ueber vom
Administrator anderswo definierten "Kleber": Im einfachsten Fall
eine reservierte Variable, die eine Liste der im folgenden
automatisch aufzurufenden Flexe enthaelt.

Absolut triviales Beispiel (fuer einen Aspekt der Katalogisierung,
dessen "Geschaeftsgangshaftigkeit" ich jetzt einmal behaupte):

Das Zusammenspiel von oninput.flx (Einstiegspunkt, recht invariant),
input.vw (sichtbar), input.flx und cat.frm (sichtbar) ist so komplex,
dass es (insbesondere, aber nicht nur) von Anwendern nicht mehr
beeinflussbar ist. Die erste Verbesserungsmoeglichkeit besteht
darin, in input.vw statt eines temporaeren Kuerzels den echten
Namen des gewuenschten (Start-)Formulars zu hinterlegen (sowie
die gewuenschte Dateinummer, oninput.flx muss das dann
auseinanderdroeseln).

x var "10=Buch,Erschl"\ins #uFo\exec input|Normaler Satz (Buch)


sagt: Neusatz fuer Datei 10, zuerst das (erste) Formular "[Buch ...]"
praesentieren, anschliessend das (erste) Formular "[Erschliessung ...]

Worauf ich hinauswill, ist aber die zweite, auch nicht weiter
schwierige Verbesserung, der auch von onforms.flx genutzt wird:

[Buch: Teil 1]
<00 b?8a
<uFnBuch: Teil 2
#40 "Verfasser: "

besagt: Wenn jemand dieses Formular (als erstes) "[Buch: Teil 1]"
aktiviert hatte, wird er normalerweise als naechstes "[Buch: Teil 2]"
bearbeiten wollen.

input.flx und onforms.flx sind dann so umgebaut, dass das funktioniert,
mit dem Ergebnis, dass die ganze "Geschaeftsgangslogik" (bis auf den
Fall "hierarchischer Untersatz") aus diesen Flexen eliminiert werden
kann.

Beim Schreiben dieser Mail faellt mir erst auf, dass hier ein ganz
interessantes Zusammenspiel zwischen zentraler und lokaler
Konfigurationsmoeglichkeit vorliegt:

input.vw sehe ich als zentral an: Jede Zeile "definiert" eine
Materialart und die logischen Bloecke ihrer Behandlung (obiges
Beispiel enthaelt z.B. die Aussage, dass monographische Literatur
typischerweise unmittelbar nach der Formalerschliessung durch
dieselbe Person sachlich erschlossen wird).

Die .frm-Datei hingegen enthaelt lokale Konfigurationselemente,
Im Zusammenhang mit den jeweiligen Formulardefinitionen wird quasi
beilaeufig eine ganz kleinschrittige Ablauflogik definiert, die
sich ja v.a. daraus ergibt, dass nicht alles jeweils zu Erfragende
in 10+4 Zeilen passt, und ansonsten fuers Grosse Ganze nicht wirklich
von Belang ist.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBR86hbGITJZieluOzAQIb5AP/at0YRJWwVQlMSKi4lskhCrqBkqqumz8s
Qnad5PIRgLe4hxrvhpAoyPdcjaKey9lotjZe2cIef7pYHmMqz8qtmUJVJNM3zYbx
4Xt/nhza/5oy17gbqMwJEfhjagqU3UMYn+3vtb8uTPvv1DxarExDS5j0l7NCIYXT
+yEM7YnBf9Y=
=4biX
-----END PGP SIGNATURE-----