[Allegro] Web-Kataloge - wie ist der Bedarf?

[Thomas Berger]

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

Lieber Herr Henkel, liebe Liste,


>> Im Laufe der Jahre gab es minimale Verbesserungen und Fehlerkorrekturen,
>> es stellte sich leider heraus, dass die Anwender sich selbst in
>> eine Sackgasse manoevriert hatten und kein OPAC je aktualisiert wurde:
>> Weil niemand eine Archivkopie des Softwarestands gemacht hat, von dem
>> aus dann die lokalen Anpassungen vorgenommen wurden, war niemand in
>> der Lage, bei verbesserten Versionen entweder die wenigen Zeilen
>> geaenderten Code zu identifizieren und in der eigenen Variante
>> nachzutragen, oder die eigenen Aenderungen zu ueberblicken und in
>> der neuen Version nachzutragen, was ja aufs gleiche herauskaeme.
> 
> Ich fürchte, das haben "Komplettlösungen" so an sich. Es ist im
> allgemeinen schwieriger, diese bei Bedarf durch ein Upgrade zu ersetzen, 
> als z.B. einzelne Funktionen oder einen include File auszuwechseln.
> Gerade *weil* es Komplettlösung ist, wird der Anwender sie eben anwenden
> ohne sich mehr als nötig in sie hineinzufinden, mit der Folge, dass er
> spätere Veränderungen, die durch ein Update auf ihn zukommen, nicht
> überschaut und in ihren Auswirkungen nicht beurteilen kann. 
> Den Aufwand, den er bei der Erstimplementation gespart hat, setzt er,
> womöglich um einiges multipliziert, im Upgradefall wieder zu.
> 
> 
> Ja, wenn man, worauf Sie, wenn ich Sie richtig verstehe, unter anderem
> abzielen, die Updates überhaupt nur noch in Konfigatiosndateien machen
> müßte, dann wäre der Anwender einer Komplettanwendung aus dem Schneider.

Update besteht im Entpacken eines Zip-Archivs, evtl. noch im
Umkopieren einer Datei. Eventuell noch in dem zarten Hinweis,
dass xy nun auch noch konfigurierbar gemacht worden ist und
man bei Lust und Laune das in seiner Konfigurationsdatei
ergaenzen kann.
Die vom Anwender erstellte Konfigurationsdatei wird nie getroffen,
und es ist Aufgabe der "Komplettloesung", 100%ige Auf- und
Abwaertskompatibilitaet der Konfigurationseinstellungen zu
gewaehrleisten.



>> Man braucht einerseits die Funktionen, die ein Interface zu
>> Avanti darstellen (mit Avanti kommunizieren, Datensatz oder
>> Indexausschnitt holen), andererseits aber auch hoeher integrierte
>> Funktionen ("mache eine Navigationsleiste zur aktuellen Ergebnismenge:
>>  "-20 -10 ... +10 +20 +50"), die dann die Bausteine fuer die
> 
> Ob das nicht über den Rahmen "Datenbankinterface" hinausgeht?
> Genügte es nicht, wenn es eine Funktion gäbe, deren Argumente die
> Anfrage "gib die nächsten 10 Einträge" oder "gib die vorhergehenden 10"
> formulieren?

Auch das geht schon darueber hinaus, denn es waere eine Funktion,
die (etwa in Form geeigneter Query-Objekte) ueber die Zustandslosigkeit
von Avanti hinausgeht und eine Recherche verwalten kann. Sonst ist
"die naechsten 10" nicht gut definiert.


> Wenn das Resultat der Anfrage in einer kommunen Form zurückggeben wird, 
> kann man eine solche Navigationsleiste entweder selbst bauen oder auf
> die im Internet verbreiteten Werkzeuge und Bausteine zurückgreifen.

Ich dachte auch nicht so sehr an den HTML-Code dieser Navigationsleiste,
sondern die einzelnen Eintraege, deren "ob" und Beschriftung hochgradig
vom aktuellen Zustand der Web-Anwendung abhaengt.



> Es kommt hier letztendlich auf eine möglichst geschickte (und wohl auch
> komplexe) Kapselung der Avanti-Kommunikation an.
> 
>> Zumndest sollte man fuer die OPAC-Anwendung CSS-Klassen "index",
>> "vollanzeige", "kopfteil", "fussteil", "navigation" etc. einfuehren.
>> (ich denke aber, das waren nicht die "Klassen", die Sie hier meinten?)
>>
> 
> Ich meinte OO-Klassen in PHP. Gibt es zum Beispiel eine Klasse Index,
> so wäre z.B. für die Arbeit mit einem Allegro-Index 
> 
> $per = new Index('PER') eine Instanz zu erzeugen
> 
> und mit 
> $entries = array();
> $entries = $per->browse('shakespeare', 50)
> 
> 50 Einträge ab "shakespeare" in dem array $entries abzuliefern.
> 
> (Das Beispiel ist fiktiv)

Soetwas ist auf jeden Fall sinnvoll. Fuer den Guiderom habe ich
(allerdings in Perl, jedoch ganz ohne Populo) ein OO-Modul
implementiert, das aehnlich vorgeht, jedoch ein XML-Dokument
als Repraesentation des Indexabschnitts praepariert, das dann
von der Awendung mittels XSLT zu HTML weiterverarbeitet wird.



>>> Beim Lesen der Datensätze würde ich Wert rauf legen, nur die
>>> Kategorien (z.B. als ass. Array mit den Kategorienummern als
> Schlüssel)> zu erhalten. Alle Modifikationen und Manipulationen an den
> Daten gehören
>>> in die Scripts un sind nicht Sache des Servers und seiner jeweiligen
>>> Ausgabe. 
>> Ich kann mit xslt 2.0 (!) in der Tat inzwischen bessere ISBD-Ausgaben
>> erzeugen als mit der Exportsprache. Bis das aber in den Servern,
>> geschweige denn in den Browsern angekommen ist, moechte ich avanti
>> an dieser Stelle nicht missen.
>>
> 
> Sofern es darum geht, bestimmte, vorher gesuchte oder ausgewählte
> Datensätze mit xport p xxx in irgendeiner bestimmten Form (z.B. für die
> Anzeige) zu formatieren, nutze ich avanti auch noch.
> Man kann das dann mit echo einfach an den Browser weitergeben.

Hm. Die Anwendung muss das normalerweise noch parsen, weil ja z.B.
interne Verlinkungen der Datenbank gewuenscht sind. Und hier
sollte die Parameterdatei keinesfalls die konkreten URLs der
OPAC-Anwendung generieren, sondern eher in Anlehnung an die
Flip-Notation "?|PER 'Shakespeare, William'" etwas abstrakteres,
das dann von der Anwendung in konkrete URLs umgeparst wird. Finde ich.



>> Das waere das Minimum, wenn man mit diesem Toolset eine eigene
>> Anwendung baut. Ich hielte es aber fuer erstrebenswert, in
>> den unterschiedlichsten Situationen eine Standardanwendung
>> nutzen zu koennen (zumindest dann, wenn die eigene Datenbank mehr
>> oder weniger eine Standarddatenbank ist).
> 
> Ob man das dann nicht auch einem CMS überlassen könnte, in dessen
> Templates die avanti-calls  der Funktionsbibliothek irgendo eingebettet
> werden?

populo ist ein solches CMS, phpac koennte es vielleicht einmal werden.
Aber Sie wollen sich die Wahl Ihres CMS nicht  vorschreiben lassen?

Eine bibliothekarische Anwendung ist ja keine RPC-Anwendung, die mal
eben schnell das Tageswetter fuer Berlin einblendet, sondern ein
komplexes Ding. D.h. selbst wenn Sie in php oder python oder einer
anderen Sprache Ihrer Wahl die Avanti-Anbindung perfekt weggekapselt
haben, bleibt noch die Anwendungslogik fuer den Katalog. Und die
muesste man fuer jedes existierende CMS in dessen Steuersprache
stets neu implementieren. Man haette dann (bei identischer
Funktionalitaet) nicht eine, sondern ca. 5 Standardanwendungen
(php, typo3, zope und diverse clones), die alle separat gepflegt
werden muessten (Alternativ kann man natuerlich den OPAC in eine
RPC-Anwendung umbauen und muss fuer die CMS'se dann nur noch
geeignete Kommunikationsklassen vorhalten, dann haette man aber
eine Kommunikationsskette Benutzer -> CMS -> OPAC-Anwendung -> Avanti
und zurueck).

viele Gruesse
Thomas Berger

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

iD8DBQFEqsGwhKFJT0F1FsoRAqXbAJ0X1bciFsuK4XcqnYQ6wZg2R4m9qwCfQCnm
FVnxmdnKa5rSjYML0DntbDc=
=0a3i
-----END PGP SIGNATURE-----