[Allegro] 64bit-welt: allegro auf dem wege dahin?

[Michael Lackhoff]

On 12.03.2012 13:28 Bernhard Eversberg wrote:

> Am 09.03.2012 20:06, schrieb Michael Lackhoff:
>>
>> A99? Was ist das? ;-)
>>
>> (Ich habe mir immer schon mal vorgenommen, die Bedienung von presto,
>> insbesondere die Abfrageliste, in einer Webanwendung mit Javascript
>> nachzubilden, bin aber leider bisher nicht dazu gekommen...)
>>
> Schätzungsweise bräuchten Sie dafür etwas länger als für die
> Einarbeitung mit a99. Welches überdies viel mehr funktionale

Nun ja, Hybris ist ja eine der Tugenden des Programmierers ;-)
Ich denke auch gar nicht, A99 oder Presto vollstaendig ersetzen zu
koennen, moechte aber doch etwas naeher erlaeutern, was mich treibt.
[ist fuer viele reine Allegrologen vermutlich uninteressant aber es gibt
ja eine Loesch-Taste].

Wie ich schon mal in einer frueheren Mail schrieb, denke ich moeglichst
in Baukaesten bzw. frei kombinierbaren Modulen.
In meinem Baukasten ist die Suche bisher sehr gut abgedeckt und auch
fuer die Datenkonvertierung habe ich einen ganzen Zoo von Perl-basierten
Modulen.
Was bisher immer fehlte ist ein Editor. Wenn ich mich nun in einer
weitgehend reinen Allegro-Umgebung bewegen wuerde, waere A99 oder
vermutlich doch eher A30 das Mittel der Wahl.
Da ich es aber mit ganz unterschiedlichen internen Datenformaten zu tun
habe, die nicht mal alle mit Kategorienummern arbeiten, wollte ich etwas
universelleres.

Ein erster Schritt dahin war eine kleine Datenuebernahmeanwendung. In
bewaehrter Baukasten-Manier schaltete ich dazu einfach hinter meine
Suche einen passenden Konverter und gab das Ergebnis aber statt in <div>
u.ae. tags in jeweils ein textarea-Feld pro Treffer aus. Da konnte man
dann noch eine Signatur anhaengen, speichern und fertig.
Da wo die Daten in eine Allegro-Datenbank einzuspielen sind, habe ich
dann in der textarea also einen ganz normalen Allegro-Datensatz im
A-Format, nur eben in UTF-8. Zum Speichern wird ein Perl-Script
aufgerufen, das noch ein paar Nacharbeiten macht und dann das Ergebnis
ueber einen trivialen Mini-Job in die Datenbank einspielt.

Das funktioniert alles sehr gut und ist wie gesagt auch sehr flexibel:
Ich kann Datenquelle, Konverter und Ziel praktisch beliebig austauschen.

Der Haken ist natuerlich, dass diese Art der Bearbeitung keinerlei
Komfort hat. Fuer reine Fremddatenuebernahmen, bei denen nur wenige
Lokalkategorien anzuhaengen sind, mag das noch angehen aber
Neukatalogisierungen moechte man damit nicht machen.

Natuerlich kann man fuer Neukatalogisate die dafuer vorgesehene
Anwendung (bei Allegro also z.B. A99) verwenden und das wird bisher ja
auch so gemacht. Ich faende es aber schoen, wenn man alles in derselben
Oberflaeche machen koennte. Typischer Anwendungsfall: es kann nur ein
Teil der Titel aus Fremddaten uebernommen werden, die uebrigen muessen
von Hand selbst eingegeben werden. Dann will man nicht immer wechseln.

Also habe ich mich am letzten Wochenende hingesetzt und trotz meiner
aeusserst bescheidenen Javascript-Kenntnisse mal was geschrieben, das
meinen Vorstellungen schon sehr nahe kommt.
Da ich ja auf die Fremddatenuebernahmeanwendung aufsetzen konnte, musste
ich mich umd das ganze Drumherum nicht mehr kuemmern, das war ja schon
da. Ich konnte mich also ganz auf die Eingabeunterstuetzung konzentrieren.

Damit es universell einsetzbar bleibt, definiere ich zwei JSON-Objekte,
eines fuer die Definition der Kategorien und eines (oder mehrere) fuer
die Definition von Abfragelisten.
Beim Durchgang durch die Abfrageliste verhaelt sich die Anwendung schon
weitgehend wie Presto. Je nach Inhalt der mit Return abgeschlossenen
Zeile werden Kategorien hinzugefuegt, Schleifen durchlaufen, Befehle
ausgefuehrt, Hinweistexte eingeblendet.
Soweit ich weiss ist doch die Abfrageliste in A99 auf der Strecke
geblieben, oder? Gerade die finde ich genial fuer die schnelle und
gefuehrte Dateneingabe. Da brauche ich zwischen den Nutzdaten nur ein
paar <RETURN>, evtl. ein "x" zum Abbruch und am Ende ein rj und fertig
ist der Datensatz.

Natuerlich ist das alles noch sehr weit von der vollen Power von presto
und vermutlich auch A99 entfernt, doch normale Dateneingaben lassen sich
damit schon sehr effektiv machen und wenn eine Funktion fehlt, kann man
zur Not ja immer noch auf das Vollprogramm ausweichen (oder eben die
Funktion hinzufuegen). Einzig die programmierte Validierung sehe ich als
etwas schwieriger an, sobald dazu Infos aus Datenbank oder Index
benoetigt werden, aber auch das laesst sich mit Ajax bei Bedarf einbauen.

> Stelle hätten Sie lieber JavaScript oder Perl. Einerseits mit
> Berechtigung, andererseits wüßten wir jedenfalls nicht, wie das
> wirklich gehen sollte. Allenfalls könnte man aber aus Perl

Ganz ohne geht es nicht, aber bisher brauche ich nur ein paar
Trivial-Flexe: Datensatz ueber ID holen, Datensatz schreiben,
Indexeintrag ueberpruefen. Die gesamte Logik steckt in Perl (und JS) und
ist damit wiederverwetbar. Beispiel: ich habe letzte Woche fuer ein
Projekt, das nichts mit Allegro zu tun hat, ein Modul zur Normalisierung
von Sprachcodes geschrieben. Das laesst sich ueber ein einfaches
to_iso639_2() einbinden. Mit Flexen haette ich dasselbe sicher auch
erreichen koennen aber wohl mit mehr (Pflege-)Aufwand.

> o.a. heraus normierte FLEXe per ExFlex an a99 absenden und die
> Resultate dann wieder auffangen, wie es auch JanaS tut.
> Alles nicht ideal, richtig, aber "Perfection's just a dream..."

Ja leider. Allerdings hat man beim Rueckgriff auf weit verbreitete
Sprachen den Vorteil, dass viele Detailprobleme schon geloest sind.
Damit kann man sich dann ganz auf das konzentrieren, wovon man noch ganz
besonders traeumt. Ich habe mir z.B. mit meiner Wochenendaktion gleich
zwei Traeume erfuellt: einen eigenen und brauchbaren Datensatzeditor zu
schreiben und meine Javascript-Kenntnisse aufzufrischen. Fuer beides
hoffe ich auch in Zukunft noch oefter Verwendung zu haben, weshalb ich
hoffe, die Zeit sinnvoll eingesetzt zu haben. Und last but not least: Es
hat einfach richtig Spass gemacht, das Teil zu bauen ;-)

Viele Gruesse und sorry fuer die Laenge der Mail
Michael Lackhoff