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

[Roland Henkel]

Lieber Herr Berger, liebe Liste,

> 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.
>
>
>   
Gut. Und wenn der Wandel derZeit es notwendig macht, das Komplettsystem 
zu renovieren, muss den Nutzer das nicht interessieren,
weil die Aussenfläche des Systems die gleiche bleibt und er nach wie vor 
lediglich seine Konfigurationsdatei(en) im Auge behalten muss.
Wenn das realisierbar ist, wäre ich auch für die einmalige Anstrengung, 
so ein Kompletttsystem zu konzipieren.

>
> 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.
>
>
>   
Die Definition der Grenze zwischen dem, was ein Komplettsystem/eine 
Funktionsbibliothek leistet und was lokal vom Anwender zu leisten ist,
ist wohl überhaupt das konzeptionelle A und O und mit der 
Geschicklichkeit und Kompromissbereitschaft, mit der  man sie zieht, 
steht und fällt vermutlich 
die Akzeptanz solcher Systeme. Prinzipiell geht es m.E. nicht so sehr 
darum, dass dem lokalen Anwender "wenig" oder "leichtes" zu tun bleibt 
(wer in vier Tagen etwa eine Exportparameterdatei austüftelt und durch 
vielfache Umstellungen von x und u  und umständlichen Tests endlich 
wenigstens auf den ersten Blick hat, was er wollte, könnte diese Zeit 
auch nutzen,  um sich in ein Komplettsystem/eine Funktionsbibliothek 
einzuarbeiten; Das müsste er ausserdem nur einmal tun), sondern darum, 
dass ihm das, was er zu tun hat, einleuchtet bzw. es einem 
Auftragnehmer  plausibel machen kann.
Sofern "Komplettsystem" den Traum impliziert, dass jeder Bibliothekar  
in einer freien Minute schnell mal eine Website aufsetzen kann,  halte 
ich  das Unterfangen  für illusorisch.  Ausserdem: Die IT-Leute wollen 
ja schliesslich auch leben ;-)

Gerade die OO-Kapselung böte die Möglichkeit,  Funktionen wie "die 
nächsten  10" zu realisieren. Den zuletzt gelesenen Indexstart- und 
endpunkt könnte man in einer nicht öffentlichen Variablen festhalten, so 
dass  "die nächsten 10" immer sinnvoll ist. Für den Fall, dass man beim 
letzten Indexeintrag  oder in anderer Richtung beim ersten angelangt 
ist, und es keine Nachfolger und Vorgänger mehr gibt,
müsste man bestimmte Rückgabewerte definieren, damit man diese Fälle im 
Script behandeln kann. 

>> 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)
>>     
>
>   
Kleine Ergänzung dazu: Korrekterweise müsste wenigstens bei der 
Instantiierung der Datenbankname xxx (= [xxx]  aus der avanti.conf) mit 
übergeben werden,
also $per = new Index('avdemo', 'PER');
>>>       
>> 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.
>
>
>   
Ja. Wenn man so etwas hat, ruft man besser nicht  echo/print sondern 
eine geeignete Parsefunktion auf, die entweder die Ausgabe gleich 
einschließt oder ein Resultat zurückgibt, dass
man dann ausgeben kann. Vermutlich ist es auch einfacher, eine 
Parameterdatei mit solch einer abstrakten Notation zu schreiben. Vor 
allem: Wenn sich die Struktur der URL einmal ändert,
muss man nicht auch noch an der Parameterdatei ändern. Vermutlich hätte 
man inzwischewn sowieso vergessen, dass auch dort Anpassungen 
vorgenommen werden müssen und wundert sich, dass
nichts mehr funktioniert.
 
Generell sollten m.E. mit Paramterdateien nur die unveränderlichen, 
formalen Dinge formatiert werden.
> populo ist ein solches CMS, phpac koennte es vielleicht einmal werden.
> Aber Sie wollen sich die Wahl Ihres CMS nicht  vorschreiben lassen?
>
>   
Warum nicht? Wenn es *das* CMS für Allegro-Anwendungen ist? Vorschreiben 
lassen würde ich es mir vielleicht nicht, aber es
ggf. aus Zweckmäßigkeitserwägungen auswählen :-)


> 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
Ich bin von der Annahme ausgegangen,  dass an einem Ort auch nur ein 
CMS  zur Anwendung kommt.
Ob die Betreuung dieses CMS  dem Aufgabenbereich der Allegrologen im 
engeren Sinne zuzurechnen ist, weiß ich nicht.
Dort, wo solche Systeme standardmäßig eingesetzt werden, gibt es wohl 
auch einen Administator o.ä., der sich damit auskennt.
Wenn die Avanti-Kommunikation entsprechend gekapselt ist und man 
(ähnlich wie für andere DB-Systeme) ein Prozedere vorgeben kann,
was man wie macht, um welche Resultate zu erreichen, könnte ein solcher 
Administator auch Allegro-DB betreuen. Denn für ihn stellt sich ja die 
Frage nicht so sehr,
"was für ein Datenbanksystem wird verwendet" sondern "mit welchen 
Mitteln bringe ich diese und jene Inhalte auf die Seite".

Mutatis mutandis gilt das auch für Webagenturen, die man eventuell mit 
der Gestaltung der Site beauftragt. 

Viele Grüsse
R. Henkel