[Allegro] Zur Zukunft von a30 - PS

[Anando Eger]

Hallo Herr Eversberg,

nur kurz:

> Sehen wir ja auch so! Nur ist, wie gesagt, dieser Grundgedanke mit
> a30 schon bis zum äußersten ausgereizt. Auf Kosten, zugegeben, des dem
> Anwender noch verbleibenden Designspielraums. 

eben. 

> > Herr Berger hat ja schon seit längerem einen solchen Ansatz umgesetzt
> > (populo), ich selbst nutze eine Templateengine unter php.
> Aber warum nicht populo. 

Weil Perl nicht im WAMP drin ist ;-) - zumindest gab das damals den Ausschlag.
Und dann nimmt man eben was man hat oder kennt ...

Herr Berger schrieb noch:

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

So sehe ich das auch. Das ist _unser_ Job - und wenn das Design dazu ein
anderer gestalten kann, bin ich glücklich ...

Viele Grüße
Anando Eger



On 30 Aug 2012 at 11:49, Bernhard Eversberg wrote:

> Am 30.08.2012 10:01, schrieb Anando Eger:
> >
> > wer so "vermessen" ist und selbst Webseiten gestalten will (dazu gehört
> > auch ein OPAC), MUSS sich mit java/javascript, html und php auskennen.
> >
> Wiewohl da was dran ist, und zwar allerhand, und das ist unbestritten,
> bleibt doch die Frage: was ist der UMFANG der Arbeiten, die ich auf
> der Designbaustelle machen muß - und damit implizit, wie viel oder
> wenig Zeit bleibt mir für die datenbankspezifischen Baustellen unter
> der Oberfläche, ohne die das Ganze doch sinnlos bliebe. Wenn mir
> natürlich ein fulltime Designer zur Seite steht, sieht das anders aus,
> als wenn alles auf meinen Schultern lastet. Aus dieser Zwickmühle,
> in der ja nun mal nicht wenige stecken, entsprang der Grundgedanke von
> a30, das Oberflächenbusiness auf ein extremes, aber wirklich radikales
> Minimum zu reduzieren, und damit dem eigentlichen Sinn der Sache die
> zeitliche Priorität zu geben. Minimiert wird außerdem der Datenverkehr
> (was kaum noch einen Designer interessiert). Beides ist mit Ihrem gewiß
> ordentlichen und programmiertechnisch sauber orthodoxen Template-Modell
> leider nicht so. Also m.a.W.: Es liegen Welten dazwischen.
> 
> > 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
> a30 schon bis zum äußersten ausgereizt. Auf Kosten, zugegeben, des dem
> Anwender noch verbleibenden Designspielraums. Der ist mit phpac größer,
> 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.
> 
> B.E.
> 
> 
> 
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro