[Allegro] FLEX + Flex = allegro + RIA (Was a30 IST)

[Bernhard Eversberg]

FLEX + Flex = allegro + RIA
===========================

Zu Beginn die Antwort auf eine lange schon offene, wenngleich kaum je
gestellte Frage:

Warum FLEX und nicht Flex?
--------------------------

Anwender, denen nichts entgeht, fragen sich seit langem, warum wir so
konsequent FLEX schreiben und nicht Flex.

Ganz einfach: "Flex" gab es schon, es ist sogar eine geschützte Marke,
und zwar gehört die der Firma Adobe:

   http://de.wikipedia.org/wiki/Adobe_Flex

Mittlerweile kann man sagen, daß Flex so eine Art Industriestandard
für "Rich Internet Applications" (RIAs) ist - es profitiert dabei vor
allem von der enormen Popularität von ActionScript, und das steht
für nichts anderes als das allgegenwärtige Flash: das ist DIE Program-
miersprache für multimediale Anwendungen im Netz.
Alle Browser können Flash-"Dokumente" (Multimedia) anzeigen, d.h. sie
haben alle ein "Plugin", mit dem Flash-Filmchen abgespielt werden
können. Eine Flex-Anwendung ist eigentlich ein Flash-Film (Dateityp
.swf, sprich "swiff"), in dem es weder Bewegtbilder noch Ton geben
muß, aber sehr viel Interaktion geben kann.

Nach ausgiebiger Prüfung und zeitraubenden Versuchen können wir nun
sagen, daß Flex und FLEX sich gut ergänzen können. Und zwar FLEX in
der avanti-Ausprägung. Will sagen, man kann Flex-RIAs entwickeln, bei
denen auf der Serverseite avanti mit FLEX zum Einsatz kommt. Denn
Flex und Flash sind Client-Techniken, sie laufen komplett im Browser
des Endnutzers ab, während FLEX/avanti auf Serverseite läuft. Es ist
einfach so, daß FLEX/avanti alle allegro-Daten liefern kann, die eine
Flex-Anwendung dem Endnutzer im Browser präsentieren soll, und die
Vorführung leistet dann eben der Flash-Player, der mit dem Nutzer
in emsige Interaktion treten kann, woraufhin wieder andere Daten
von FLEX/avanti angefordert werden. Das ist ganz grob der Ablauf.
Zugleich ist es eine AJAX-Technik, aber ohne Javascript.

Ein erstes Prototyp-Programm hatten wir schon gestern einfach mal so
in den Raum gestellt:

   http://www.biblio.tu-bs.de/db/a30

Es realisiert die Indexsuche, die Satzanzeige und auch die Bearbeitung
und das Speichern eines Satzes, dazu auch eine Erg.Mengen-Anzeige.
Nichts ist getürkt dabei, sondern was man sieht, funktioniert schon
in echt. Jedoch liegt der Funktionsumfang weit unterhalb von a99. Was
sich ändern könnte. Dieses Flex-Programm ist nicht groß, es konnte in
etwa einer Woche entwickelt werden.

Die DemoBank, auf die man hier u.a. zugreifen kann, ist eine Unicode-
Version (d.h. intern UTF-8) der normalen DemoBank. Es sind Sätze drin
mit kyrillischen, chinesischen, hebräischen und japanischen Zeichen.
(Schauen Sie im Reg. WRD mal unter "drev..." und unterhalb "zz".)
Genau dasselbe kann man mit jeder ganz normalen allegro-Datenbank
machen, auch mit anderen Konfigurationen als A.CFG. Das einzige,
worauf es ankommt, ist eine Tabelle  ad-utf.xpt für das jeweilige
Schema, und die entsprechenden u-Befehle in den Indexparametern.
An der Oberfläche, im Browser also, hat man stets UTF-8, wie schon
unter PHPAC.
Des weiteren hat man Zugriff zum allegro-OPAC der UB, zum alten VK
und zur Neutral-Datenbankversion des OPAC, alles jedoch ohne
Schreibberechtigung. Die Anbindung dieser Datenbanken kostete jeweils
nur wenige Minuten Arbeit, das ist nebenbei ein erfreuliches Resultat.

Nun aber noch etwas mehr zur Sache als solcher.

Die Liste der Vorteile ist nicht ganz kurz:

-- Der Server wird nicht mit zusätzlicher Arbeit belastet, es bleibt
      bei avanti + acon + Skriptsprache (Perl, PHP, Python)

-- jede allegro-Datenbank kann ruckzuck nutzbar gemacht werden mit
      Installation weniger Dateien - allein auf dem Server, d.h.

-- keinerlei Installation auf dem Client - jeder Browser ist geeignet
      (95 bis 98% der installierten Browser haben ein Flash-Plugin),
      alle anderen können es sich bei Bedarf schnell installieren.

-- nicht nur Windows, auch Linux und Mac als Client geeignet

-- JavaScript wird nicht gebraucht

-- zeitgemäßer, vertrauter Oberflächenkomfort in unaufdringlicher Optik

-- Programmierparadigma mit weiter Verbreitung (Industriestandard)
      Objektorientierung und XML: Kombination von ActionScript mit MXML.

-- Durch Nutzung von avanti keine weitere Programmierung in C oder C++
      nötig, allenfalls um acon auszubauen mittels der Klassenbibliothek

-- Konzept erlaubt saubere Trennung zwischen Oberfläche und Daten-
      verwaltung - mit bisherigen Web-OPACs nicht möglich
      d.h. Server wird entlastet, Oberfläche komplett im Client erledigt

-- Komfortables Entwicklungssystem, aber auch ohne Kosten eigene
      Erstellung von Client-Programmen möglich (wie z.B. der Prototyp!)

-- Kombination mit FLEX zur Erstellung eigener Funktionen ohne eigene
      Programmierung in Flex (wie FLEX in a99 und avanti/acon)

-- große Funktionsvielfalt für multimediale Elemente

-- kein Problem mehr mit Sonderzeichen beim Editieren

-- keine datenbankspezifischen Parameterdateien nötig, ein paar wenige
      allgemeingültige Parameter werden bereitgestellt.

-- sehr schnelle Ausführung aller Aktionen - geringe Bandbreite wegen
      kleiner Datenvolumina, die übertragen werden müssen

-- lizenzkostenfreie Open-Source-Quellprogramme kein Problem,
      und das heißt: Unabhängigkeit von Braunschweig bei der Entwicklung
      von RIAs mit allegro-Datenbanken im Hintergrund

-- natürlich auch Einsatz im Intranet möglich, sogar auf Einzelplatz-
      Systemen ohne Netzverbindung (wie schon mit PHPAC)

-- mit dem AIR-Konzept von Adobe können auch echte Desktop-Programme
      aus den Flex-Programmen erstellt werden. In letzter Konsequenz
      heißt dies, daß aus a30 am Ende ein Ersatz für a99 werden könnte.
      (RIA rückwärts gelesen ist AIR).

Und der oder die Haken?
Nicht anders als bei PHPAC liegt das größte Problem darin, daß es sich
bei Flex um ein Client-Server-Paradigma handelt. Das sehen heute
eingefleischte Softwerker nicht als Nachteil, sondern als normal an,
es bedeutet aber immer noch, daß der Anwender eben weniger "dicht dran"
ist an der Datenbank, weswegen Interaktivität nicht immer so schnell
sein kann wie bei a99. Und der Entwickler hat sich auf zwei Plätzen
zu tummeln, eben beim Client und beim Server, und beides muß zu einer
oberflächlich nahtlos erscheinenden Einheit verschweißt werden. Das ist
schwerer als Desktop-Programmierung, ganz klar. Mit PHP+FLEX auf der
Seite des Servers und Flex beim Client scheint aber ein Weg gefunden
zu sein, auf dem man einiges erreichen kann - siehe oben. Die Lernkurve
für Flex ist zwar steil, aber mit dem Prototyp-Programm haben wir ihr
schon den ersten Anstieg und die Spitze genommen: man kann es als
Basislager nehmen: Man sieht darin viele Dinge, die nicht ganz leicht
rauszufinden sind, und kann davon abkupfern und darauf aufsetzen.

Was haben wir nun vor damit?
Vor einer Weile hatten wir ja verbreitet, daß die für 2010 anstehende
V30 wieder einmal neue Akzente setzen solle. Inzwischen hat sich die
Planung und das Experimentierstadium soweit konkretisiert, daß wir von
Flex+FLEX als neuer Plattform für netzbasierte Anwendungen ausgehen
können.
Wir hatten ferner verbreitet, daß ein allmählicher Übergang des
gesamten allegro-Systems zu einem Open-Source-Paket geplant ist.
Das bedeutet in der Summe, daß man um die Zukunft des Systems keine
Sorgen mehr zu haben braucht: Unabhängigkeit von "Braunschweig" wird
erreicht werden, und das auf einem denkbar hohen und modernen software-
technischen Niveau.

Um die neuen Möglichkeiten, nicht nur das Flex+FLEX-Konzept, sondern
Entwicklungstechniken und neue Web-Verfahren ganz allgemein,
interessierten und angehenden Experten vorzustellen und es ausführlich
zu diskutieren, schwebt uns ein Expertentreffen im November diesen
Jahres vor. Hinkommen kann auch, wer nicht selber in Flex programmieren
will, sondern nur z.B. so etwas wie a30 dann einsetzen und zu lernen
wie man damit umgeht beim Einsatz in der eigenen Umgebung.
Wer daran interessiert ist, kann sich gerne schon einmal
unverbindlich melden, einfach formlos direkt bei mir, damit wir schon
mal den Umfang abschätzen können, und welcher Saal dann zu reservieren
sein wird...
Bis dahin werden wir weitere Erfahrung sammeln, Module und Komponenten
programmieren und alles so ausführlich dokumentieren, daß dann auf
dieser Grundlage andere Entwickler auf hohem Niveau starten können,
d.h. ohne erst selber die einfacheren Dinge herausfinden zu müssen.
Die Produktivität der Entwicklungsarbeit, das läßt sich schon sagen,
wird dadurch enorm gesteigert, die Produkte werden unvergleichlich
viel ansprechender, dynamischer, offener und leichter zu pflegen.
Plattformunabhängige Oberflächenentwicklung, einst kaum machbar, wird
nun tatsächlich zur leichtesten der Übungen.

Dieser Komplex ist gleichwohl nur die Enthüllung Nummer 1 des Jahres.
Eine andere steht bevor, die ein weiterer Grund sein kann, mal wieder
nach Braunschweig zu pilgern. Mehr dazu später.

B.E.