[Allegro] Zur Zukunft von a30 - PS

[Thomas Berger]

Lieber Herr Eversberg, lieber Herr Eger,

>> Wenn phpac moderisiert werden sollte, dann würde ich die Entwicklung
>> in Richtung Trennung von Formatvorlage (Stichwort "Template") und
>> Datenpräsentation bzw. -bereitstellung vorantreiben. Dadurch kann man die
>> die Arbeiten zum Design auskoppeln und evtl. unabhängig von
>> Allegro/Flex-Kenntnissen erledigen (lassen).
>>
> Sehen wir ja auch so! Nur ist, wie gesagt, dieser Grundgedanke mit

Ich halte PHPAC (abgesehen von der Unwartbarkeit aufgrund der von
Herrn Eger angedeuteten Designprobleme) von der Funktionalitaet her
fuer ziemlich grottig, (sogar noch einen Tick schlechter als die
Aleph-500-OPACs, falls das geht). Ein /Katalog/ sollte doch mehr
koennen als nur aus allen Ecken moeglichst schnell auf die
Einzeltitelanzeige in einem separat-Fensterchen zu leiten, woraufhin
man dann anscheinend lossprinten soll und fuer den Rest des Tages
nicht mehr an den Rechner zurueckkehrt.


> a30 schon bis zum äußersten ausgereizt. Auf Kosten, zugegeben, des dem
> Anwender noch verbleibenden Designspielraums. Der ist mit phpac größer,

Eine Anregung war bereits 2009, die a30-Ideen mit "Destinations"
oder "Streams" aufzugreifen und genau dasselbe standardkonform
in HTML5 und JavaScript/DOM nachzuprogrammieren.


> in der Anlage und internen Strukturierung jedoch weit hinter dem
> heutigen Stand der Kunst. (Wer sich auf ActionScript einließe, hätte
> freilich mit a30 ganz schnell die Nase vorn gegenüber allem andern,
> aber das ist rein hypothetisch.)
> 
>> Herr Berger hat ja schon seit längerem einen solchen Ansatz umgesetzt
>> (populo), ich selbst nutze eine Templateengine unter php.
> Aber warum nicht populo. Bzw. umgekehrt, warum nutzt Berger nicht Ihren
> Template-Ansatz? Aber gut, so hat man zwei zur Auswahl, wenn man weder
> phpac noch a30 zuneigt. Jedes Modell ist das beste - für den, der damit
> besser (vor allem schneller) klarkommt als mit den anderen.

Typischerweise ist heutzutage das Layout ja vorgegeben, bzw. konkret
in einem CMS bereits implementiert. Anfangs sind immer alle ganz
schrecklich enttaeuscht, dass es zu ihrem Lieblings-CMS kein
allegro-Plugin gibt und auch keine PHP- (typoscript, whatever) SQL-
Bindings fuer allegro, damit die Designer mal eben schnell selber
eine Kataloganwendung zusammenkloppen koennen.

Ich sehe einen (allegro-)Katalog als eigenstaendige Web-Applikation,
die neben einem nicht ganz trivialen Datenmodell (speziell wenn es
auch Normdaten gibt) allerhand interne Zustaende hat (also nicht nur
a) Suchmaske b) Ergebnisanzeige), sowie auf die Eigenheiten des
Bibliothekswesens angepasstes Rechercheverhalten (wer analysiert sonst
schon out-of-the box, ob eine Eingabe ein ", " enthaelt und daher
ein abendlaendischer Name sein koennte) und auch noch diverse Zusatz-
funktionaelitaeten bieten sollte (Weiterleitung auf KVK und ZDB
oder EZB und URN-Resolver, Mashups zu diesem und jenem).

Gegen den Ansatz "mal eben schnell an einem Nachmittag" spricht daher
auch, dass ein Katalog seine Funktionalitaet staendig fortentwickeln
sollte. Das macht aber die von Herrn Eger angemahnte Trennung von
Funktionalitaet und Layout wirklich zwingend, denn die Anwendung
muss update-bar sein, ohne dass aufwendiges Nachfuehren oder sogar
komplette Neudurchfuehrungen der lokalen Layoutanpassungen noetig
werden.

viele Gruesse
Thomas Berger