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

Di Jul 4 15:39:59 CEST 2006

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

Lieber Herr Henkel, liebe Liste,

>> Wir wissen auch nicht, ob eher ein Interesse an Komplettlösungen
>> besteht, die möglichst komfortabel ausgebaut sind (wie wir es mit
>> phpac versuchen)

Nice try...

> Solche Komplettlösungen müssen m.E. für konkrete Anwendungen doch immer  
> modifiziert/adaptiert werden. Ich könnte sie mir allenfalls in
> Verbindung mit einer ganz bestimmten Datenbankkonfiguration (z.B. a-
> oder n-Format vorstellen. Für Nutzer, die ihre Aufgaben mit diesen
> Konfigurationen lösen wollen oder können, wäre das dann sicher
> hilfreich. Alledings wird es doch je Anwendung verschiedene Wünsche und
> Anforderungen bezüglich des Layouts und der Benutzerführung geben, so
> daß ein Komplettpaket eben doch nur ein Gerüst ist. Für mich stellt sich
> deshalb die Frage, ob der Aufwand, ein solches Komplettpaket zu
> erstellen, in Anbetracht dessen, dass es denn doch eigentlich nicht
> komplett ist und noch weiter angepasst werden muss, nicht zu hoch ist.

Der Aufwand ist extrem hoch, aber m.E. notwendig. Fuer allegro-HANS
gab es z.B. seit 1997 einen OPAC "von der Stange", den die Anwender
normalerweise selber adaptiert haben (Layout, Logos, Fusstabschnitte der
Seiten, einzelne Register fuer die Recherche ergaenzt, also nichts
wirklich wildes). Das Ganze war in/mit Populo realisiert, d.h. es
gab populo.pl als "Bibliothek" (kein Anwender hat je darin eingreifen
muessen, das ist ein Erfolg), Templates mit Platzhaltern fuer die
Avanti-Jobs mit manchmal komplexer Suchlogik (auch hier hat selten
jemand eingreifen muessen, manche Schranken waren damals leider
hardcodiert eingestellt), Templates fuer die Ausgabe und einem
CGI-Skript, das die Datenbankeigentuemlichkeiten (Parsen der
Kurztitelliste, Name der Bibliothek) vermerkte.

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 habe daher letztes Jahr die Angelegenheit gruendlich ueberarbeitet
und zwei neue Konfigurations-"Ebenen" eingefuehrt:

* Das, was frueher das "lokale" Perlskript mit den Datenbank-
  eigentuemlichkeiten war, sollte nun ueberhaupt nicht mehr angefasst
  werden, es enthaelt nun generelle Einstellungen fuer HANS-Datenbanken
  und die allgemeine Logik dieser Web-Anwendung. Dafuer gibt es nun
  eine weitere Konfiturationsdatei (in Perl-Syntax, typischerweise aber
  nur Variablenzuweisungen), in der Bibliotheksname, Stylesheets,
  Anzubietende Register, Eingabebeispiele, Kopf- und Fussteile als
  Standard bzw. selbstgelieferte HTML-Fragmente etc. eingestellt
  werden koennen (aber nicht muessen: Die Anwendung liefert auch
  ohne Konfigurationsdatei noch Ergebnisse, nur der Bibliotheksname
  stimmt normalerweise nie ;-)

...
# oder Modifikation des Standard-Headers
# ausschalten per CSS: div.hansopac_stdtop
#$LogoLeft = "";
# formatieren per CSS: td#hansopac_stdtop_logoleft
#$LogoMiddle = "";
# formatieren per CSS: td#hansopac_stdtop_logomiddle
#$LogoRight = <<"XxX";
#<img src="/hansimg/uballegr.gif" ALT="allegro-C Logo" align="right" />
#XxX
# formatieren per CSS: td#hansopac_stdtop_logoright

# Linkbeschriftung "Home" im Auswahl-Frame (verlinkt auf ORGHomeURL, siehe
# Standardfussabschnitt)
#$ORGHomeName = "Startseite";

* Die Templates wurden auf als HTML4.01 verkleidetes XHTML umgestellt
  und in zwei Ebenen "durchgestylt": Einerseits ein Satz von Klassen
  fuer den OPAC als Anwendung, andererseits ein Satz von Klassen fuer
  die Datensatzvollanzeige (Die HANS-Datenstatzanzeige liefert
  gluecklicherweise korrektes - und auch reiches - HTML, fuer das
  A-Schema ist da nichts auch nur in Sicht). Anwender erzeugen eine
  CSS-Datei, die das Instituts-allgemeine CSS-Stylesheet einbindet,
  danach das HANS-Allgemeine und dann noch spezielle Setzungen
  enthaelt, etwa (das folgende ist nicht exakt ein HANS-Beispiel)

/* basic styling by acxt-opac.css */
@import url(vwv.css);
@import url(populo.css);

/* overrides and extensions */
/* OPAC-Oberflaeche wie .grafbody aus vwv.css */

body.populo_main {
 font-family:Verdana,sans-serif;
 margin-left:50px;
 background-image:url(images/symbole/hpbkgd.gif);
 background-color:#CCCCCC;
 background-repeat:repeat-y;
}

tr.populo_indexrow_odd, tr.populo_expndrow_odd, tr.populo_shortrow_odd {
	background-color: #e8e8e8;
}
tr.populo_indexrow_even, tr.populo_expndrow_even, tr.populo_shortrow_even {
	background-color: #c8c8c8;
}

Wer nicht weiss, wie man eine css-Datei baut, muss in der
Konfigurationsdatei alle externen Stylesheets auflisten...
[Ungeloest ist das Problem, dass hochkomplexe Instituts-Stylesheets
von Leuten, die ueberhaupt keine Ahnung von CSS haben, auf die
Datenbankanwendung aufgepfropft werden muss: Wenn das Technologie-
gefaelle *innerhalb* der anwendenden Institution zu gross ist,
hilft nur outsourcen ;-)

HANS-Anwender sollten mit diesem Instrumentarium in der Lage sein,
Ihren OPAC einmal aufzusetzen, danach aber durch Entpacken neuer
Versionen zu aktualisieren, ohne die eigenen Anpassungen zu
gefaehrden.

In der Pipeline ist bei mir eine Neuentwicklung eines Interfaces
fuer die Avdemo-Datenbank (und andere), das neben den genannten
noch weitere Konfigurationsebenen enthaelt, die sich als ebenfalls
notwendig erwiesen haben:

* i18n/l10n: Urspruenglich waren die Populo-Templates so gemacht,
  dass fuer eine Uebersetzung das Interface (incl. HTML-Templates)
  "geklont" werden sollte: Wenn die Uebersetzung eines Textes
  dreimal laenger ist als das Original, muss man evtl. ganz anders
  formatieren. In der Praxis fuehrt aber auch das wieder dazu, dass
  Einfuegen eines   oder andere Winzigkeiten in die Uebersetzungen
  nicht nachgezogen wird. Fuer Hilfeseiten wird es auch weiter so
  bleiben, die "normalen"-OPAC-Seiten werden nun aber fuer
  Uebersetzungen aus vom Anwender pflegbaren Dateien mit den
  Anzeigebestandteilen gespeist:

    <caption name="Zeitfilter">
      <resolv lang="de">Zeitl. Zuordnung</resolv>
      <resolv lang="en">time references</resolv>
      <resolv lang="sk">časový údaj (letopočet)</resolv>
      <resolv lang="pl">Okres (w latach)</resolv>
      <resolv lang="cs">časový údaj (v letech)</resolv>
      <resolv lang="li">Laikotarpis (metais)</resolv>
      <resolv lang="hu">Időrendi beosztás</resolv>
    </caption>

* CMS-Integration: Oft ist es ja nicht mit der Uebernahme eines
  Instituts-Layouts getan, sondern der gesamte Auftritt ist eine
  durch ein CMS realisierte *Anwendung*. Hier gibt es keine
  allgemeine Loesung, dazu sind die CMS zu unterschiedlich in
  ihren Faehigkeiten (je weniger man Ruecksicht auf den Rest
  der Welt nimmt, umso einfacher ist das CMS und umgekehrt). Mehrfach
  hat es aber funktioniert, im CMS eine Platzhalterseite vorzuhalten,
  die eine spezielle Markierung  oder
  so enthaelt, eine zeitgesteuerte Routine baut dann taeglich aus
  dieser Platzhalterseite und den Grund-Templates die tatsaechlichen
  Templates, die die Datenbank dann fuer den Rest des Tages nutzt.
  Prominentes Beispiel fuer diesen Ansatz ist http://www.litdok.de/

>  oder an so etwas wie der Funktionsbibliothek, für
> 
> eine Funktionsbiblitohek scheint mir flexibler. Was könnte sie
> enthalten?: Auslesen von Indexausschnitten (von-bis oder Anfangswert +
> n), Blättern im Index in bestimmter Schrittweite (get next, get prev)
> Suchfunktionen aller Art, Laden von Datensätzen entweder aus der
> Ergebnismenge oder über ihre Satznummern. 
> Im Grunde sind ja die Funktionen, die man für eine Präsentation der
> Daten einer Allegro-DB benötigt, abzählbar. Vermutlich kann man sie auch
> in elementare und und auf diesen aufsetzende strukturieren.

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
OPAC-Anwendung sind.

> Auch die Überlegung, ob man Klassen (z.B. eine Klasse Index, eine Klasse
> Datensatz usw.) einführen sollte, scheint mir nicht überflüssig. Ich
> habe das mal in einer kleinen Anwendung gemacht und festgestellt, dass
> die PHP-Programmierung dadurch sich erheblich vereinfacht und die
> Scripts übersichtlicher werden. 

Zumindest 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?)

> Beim Lesen der Datensätze würde ich Wert darauf 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 und 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.

> Ich halte es für sehr ungünstig, wenn der Server nicht nur die Daten
> liefert, sondern gleichsam noch HTML-Versatzstücke dazu, so verlockend
> das zuweilen angesichts der Möglichkeit von Flexen und sonstigen
> allegro-eigentümlichen Manipulationsvarianten sein mag. Wer soll
> langfristig eine solche Website pflegen und später Änderungen daran
> vornehmen? 

Das war der Grund, warum ich inzwischen zwei CSS-Ebenen eingefuehrt
habe: Die Parameterdatei liefert HTML mit vielen ISBD-bezogenen
strukturierungen, oberste Ebene ist dabei *ein* Datensatz:
<div class="hans_record">
...
</div>
<div class="hans_record">
...
</div>

>> deren Anwendung aber einiges an Kenntnissen und Zeit nötig ist. Im
>> Prinzip wäre damit sehr viel zu gewinnen, besonders wenn man
>> JavaScript noch hinzunimmt.
>>
> Dem stimme ich voll zu.
> 
> Ich könnte mir eine Funktionsbibliothek vorstellen, die man per
> include_once in seine Seiten einbindet, wenn und wo man ihre Funktionen
> benötigt.

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).

viele Gruesse
Thomas Berger

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

iD8DBQFEqm+vhKFJT0F1FsoRAuhuAJ97sXX2R8kF5hqiW8crd951CceeZgCZAbwZ
2SH4sAAP/tvWVWMi+uk1Dog=
=qy2Q
-----END PGP SIGNATURE-----