[Allegro] Frage zu h-php.apr

[Thomas Berger]

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

Lieber Herr Eversberg,

> Schlaumeierische Andeutungen über theoretisch saubere Ansätze, die
> man praktisch gar nicht umsetzen kann, sind wenig hilfreich.

Nun, nehmen wir einmal als theoretischen Ansatz, "Kinderarbeit" sei
verboten.

Praktisch bedeutet das, dass Resultate aus Parameterdateien vom
avanti/acon-Job oder vom php-Skript verarbeitet werden sollen,
oder vom Job generierte Texte durch PHP nachbearbeitet, aber nicht
umgekehrt.

Im konkreten Fall ist gerade die qrix-Ausgabe voellig
konfigurationsunabhaengig und kann gerade wegen ihrer Steuerzeichen
gut durch PHP aufbereitet werden. Stattdessen drueckt der avanti-Job
das Resultat "nach unten" in eine Parameterdatei, die fest eincodiert
u.a. den Namen der aufrufenden php-Seite, den Namen einer
Javascript-Funktion (was ist, wenn die mal anders heissen?) enthaelt
und typische Layoutaufgaben (Aufbau eines Formulars, Formatieren einer
HTML-Tabelle) uebernimmt. Das wird dann an den Job zurueckgereicht,
an das Skript uebertragen, das das Resultat dann wohl nur "einsetzt"
und an den Browser uebertraegt.

[Eine Ausnahme sind allerdings die von mir geliebten ISBD-Vollanzeigen:
Hier halte ich es fuer optimal, wenn die Parameterdatei den
Datenbankinhalt zu lesbarem Text verdichtet, der dennoch Markup
enthalten sollte: Dieses sollte aber nur aus generischem (X)HTML ohne
konkrete Formatierung bestehen, d.h. div's und span's, auch p's und
Listen, jeweils extensiv mit class-Attributen versehen]


> Überdies sagen wir nie, daß alle PHPAC machen sollten. Wer Perl kann,
> dem empfehlen wir immer Populo. Und wer sich Verdienste erwerben will,

(ich will niemandem zu nahe treten, aber populo-Anwender, die Perl
koennen, sind mir nicht bekannt).

> der krittelt nicht an existierenden Lösungen rum, der macht ein gänzlich
> neues, rundum überzeugendes Anwendungspaket auf der Höhe der Zeit.

[die "Allegro-Methode" ist ja eher Redesign bewaehrter Anwendungen ;-),
daher]

http://frodo.ulb.uni-bonn.de/guiderom/ von 2004 sieht zwar so aus wie
die aelteren Guides von Herrn Fischer, ist aber weitgehend eine
XML-Anwendung: Moeglichst tief unten (Parameterdatei, Job, hilfsweise
Bibliotheksfunktion im CGI-Skript) wird alles zu XML gemacht und
dann mit serverseitigem XSLT formatiert (gluecklicherweise werden
hier ISBD-Anzeigen nicht benoetigt).

Ansonsten (Ankuendigung des "public beta" erfolgt demnaechst) habe ich
populo so aufgepeppt, dass es die Unicode-Behandlung an avanti delegiert
(dafuer ist allerdings "Kinderarbeit" erforderlich: Umwandlung der
Ausgaben nach UTF-8 erfordert vorheriges "dow wX", ergo eine
Parameterdatei im Stil von e-u.apr) und vor allem einen zeitgemaessen
Demo-OPAC spendiert, der konsequent mit CSS arbeitet und fuer das
Standardschema geeignete Parameterdateien liefert, die - nach langen
Muehen - inzwischen wohl tatsaechlich balanciertes (X)HTML produzieren
koennen:

http://avdemo.gymel.com/
http://capdemo.gymel.com/

Darin steckt eine gewisse Abkehr von frueheren Prinzipien bzw. eine
Entwicklung: Urspruenglich war (und ist auch heute) populo eine
Art Baukastensystem mit Grundfunktionen, aus denen sich ein Anwender
eine eigene Anwendung zusammenbauen kann: Er entwirft ein paar
HTML-Templates, ein paar Jobs und traegt ansonsten ein paar variable
Inhalte (Name der Anwendung, Registerbenennungen, benoetigte [und
guenstigenfalls bereits vorhandene] Parameterdateien) in einem kleinen
Perlskript ein.

Im Laufe der Jahre stellte sich aber heraus, dass ein Online-Katalog
eine hochkomplexe Anwendung ist, was zwar abgemildert wird dadurch,
dass man eine allegro-Datenbank hat und nicht etwas relationales,
aber die "kleinen Perlskripte" oben wurden fuer alle von mir
betreuten Anwendungen immer aufwendiger, weil anwendungsabhaengige
Aufgaben wie die Aufbereitung von Suchbegriffen oder externe
Verlinkungen (ZDB, EZB, KVK, PND, ...) hinzukamen. Aussserdem gab es
wenig Bedarf oder Phantasie, neben Index, statischen oder dynamischen
Systematiken, Kurzliste und Vollanzeige noch weitere Betriebsmodi der
Datenbanken einzufuehren, stattdessen immer mehr Bedarf, existierende
und meist extern entstandene Gesamt-Layouts (aus CMS'en, mit Tabellen
oder (i)Frames oder Floats) einer Katalogloesung moeglichst schmerzfrei
ueberzustuelpen. Die Webdesigner der Gesamtloesungen gehen allerdings
oft davon aus, dass jede zukuenftige Anwendung noch nicht existiert,
sondern mit den Mitteln des von Ihnen eingesetzten CMS neu programmiert
wird. Die Anwendung muss daher nicht ganz triviale Vorkehrungen treffen,
mittels derer sie weitgehend so tut, als sei sie aus dem CMS oder
sonstigem Verwaltungsschema geboren, was dann die HTML-Templates wieder
kompliziert macht. Und selbst die CSS-Styles mussten irgendwann (aber
dazu hat CSS ja die "Kaskade" bereits im Namen) in "einfache" und
komplexe, moeglichst nicht durch den Anwender zu veraendernde Teile
aufgedroeselt werden, damit den durch Uebernahme von Styles fuer die
eher statischen Inhalte der Gesamtpraesenz auftretenden Probleme
gegengesteuert werden kann. Und die Uebersetzung der Oberflaeche in
verschiedene Sprachen hatte ich mir vor 10 Jahren auch einfacher
vorgestellt, inzwischen weiss ich, dass es selbst ins Englische nicht
wirklich trivial ist und die Anwendung das moeglichst "mitbringen"
sollte.

Die Erfahrung ist also leider, dass sich eine Kataloganwendung nicht
quasi beilaeufig definieren laesst (wobei zugegebenermassen nie
versucht wurde, die "richtigen", universellen Python-Klassen oder
PHP-Bibliotheken im Kontext aller existierenden CMS'e bereitzustellen),
und dass die Bemuehungen, dennoch (und moeglichst ohne nennenswerte
Individualprogrammierung) eine optisch nahtlose Integration in jede
beliebige Umgebung zu ermoeglichen, der halbwegs komplexen Anwendung
"Katalog" noch gewaltige Zusatzkomplexitaet aufbuerden, so dass das
Resultat dann ein ziemliches Anwendungs-Schwergewicht ist mit nur
noch ganz wenigen gefahrlos vom Benutzer einstellbaren Stellen.

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

iQCVAwUBSPcmq2ITJZieluOzAQKecwP+LJ0/07z3RNKgxXD/58azqjZ8VzMbYJYR
GU3y9p8gpRZ4tSQ7a+ETyHDgwqSTUBPVqbzd1kUidR5BWZHXmFMk1RNGoDl9VgKD
xf2U05nXF8DVVYpY0CDoSEVGXabDuSclSvbHxco9qMdQxxE70QsifZyOQEzEpjPS
AbAT0V1gZHU=
=yi8N
-----END PGP SIGNATURE-----