[Allegro] Viva la liberta! Freischwebende FreiRäume

[Bernhard Eversberg]

Viva la libertà! Freischwebende FreiRäume

    Neue Beispiele:
       http://www.biblio.tu-bs.de/db/a30/demo.htm
    Erweiterte Doku:
       http://www.allegro-c.de/doku/a30/frr.htm
    Bereitstellung der neuen Dateien:
       Voraussichtlich nächsten Dienstag


Will man richtig dynamische Dialoge konfigurieren, ist ein einziger
FreiRaum doch arg wenig. Darüber wurde nochmal im engsten Zirkel
diskutiert, hier das Ergebnis:

Erstens ist es mißlich, daß der FreiRaum nicht zugleich mit einem der
anderen Tabs nebeneinander betrachtet werden kann!

Zweitens: man will auch mal aus dem FreiRaum heraus ein anderes
Formular heranholen, wobei dann aber der FreiRaum-Inhalt während der
Zeit bestehenbleiben und sichtbar bleiben soll!

Noch ein oder mehr zusätzliche FreiRaum-Tabs wären aus diesen Gründen
nicht die Lösung.
Nein, man braucht zwei, drei, viele *freischwebende* FreiRäume, jeder
davon unabhängig von den anderen mit beliebigem Inhalt bestückt, jeder
in der Lage, mit eigenen Buttons eigene Jobs zu starten, die dann ihm
selber oder anderen Freiräumen Daten zukommen lassen.

Nur nebenbei:
Was man *auch* machen kann, ist das Öffnen eines (kleineren) Browser-
fensters mit einem Hyperlink der Form  event:S:url
wobei die (dynamische) url dann wieder Daten für den FreiRaum liefert.
Das aber kann nicht für alles schon die Lösung sein, vor allem weil die
so generierten Fenster dann kein Teil von a30 sind, aber auch, weil
nicht alle Browser damit in gleicher Weise umgehen, z.B. IE anders als
Firefox!

Die Strategie der einfachstmöglichen Lösung legt nahe, es so zu machen:

1. Öffnen eines weiteren FreiRaums als eigenes Fenster mit

    _!_FREi

    wobei i eine Ziffer 0..9 sein soll, ohne Spatium davor.
    (Ohne i ist es der "alte" FreiRaum unter dem Tab neben "Menu".)

2. Nachfolgend dann alle Elemente für den neuen FreiRaum, genauso wie
    bisher bei dem mit  _!_FRE  eingeleiteten Tab

3. Aber es geht damit eben ein eigenes (kleineres) Fenster auf, in dem
    die Elemente dann erscheinen.

4. Jeder freischwebende FreiRaum kann also auch eigene Buttons haben,
    hinter denen jeweils ein Job steckt.

5. Automatisch hat das Fenster einen Button, der es zumacht. Es wird
    dann aber nur unsichtbar; beim nächsten _!_FREi wieder sichtbar.

6. Mit  _!_FREi +  kann man auch einem einmal eingerichteten FreiRaum
    später weitere Daten zusenden (s. "... in der Tiefe des FreiRaumes")
    Folgt nichts weiter hinter diesem Label, wird nur das vorher ge-
    schlossene Fenster wieder sichtbar.

Das weitere Durchdenken erbrachte noch folgende Bedenken:

-- In den X verschiedenen FreiRäumen können Daten aus X verschiedenen
    Datensätzen stehen! Beim Absenden muß natürlich an den Job die
    richtige Satznummer mitgeliefert werden, falls ein Schreibvorgang
    auszuführen ist.

-- Es können sogar Y verschiedene Sätze involviert sein, denn ein
    FreiRaum kann mehrere Buttons haben, und warum sollten sich alle auf
    denselben Satz beziehen?

Daraus ist zu schließen, daß die Satznummer jeweils an den Button anzu-
binden ist, nicht an das betr. Fenster. Das muß auch für den "alten"
FreiRaum gelten. (Sämtliche FreiRäume müssen in allen Belangen
funktional identisch sein, in ihren Daten aber säuberlich getrennt.)
Doch nicht nur die Satznummer, auch der Zeitstempel muß dabei sein,
weil das Speichern nur geht, wenn man diesen mitliefert und er
identisch ist mit dem, der momentan in der Datenbank steht.
Speichern, auch das ist klar, darf nur gehen nach vorhergehender
Authentifizierung.

Die Syntax für den Button ist deshalb wie folgt zu erweitern:

BU aufschrift|[-]jobname|variablen|satznr zeitstempel

d.h. so muß man im Datenstrom den Button konfigurieren, falls in dem
Job "jobname.job" ein Speichervorgang für einen bestimmten Satz
erfolgen soll.
Ein - vor dem jobname soll bewirken, daß der Button zugleich das
Fenster zumacht. Soll dies nur passieren, wenn die Aktion erfolgreich
war, dann muß man es vom Job aus bewirken, indem man darin einen
Befehl  _!_FREi -  unterbringt.

Fehlt das letzte Argument, werden diese Angaben von dem Satz genommen,
der vorher zuletzt in INT/EXT geladen wurde, d.h. auf diesen bezieht
sich dann ein put, das im Job steht - falls dieser nicht selber einen
anderen Satz lädt.
Fehlen auch die "variablen", wird dafür "all" eingesetzt. Dann werden
alle in dem Fenster liegenden V-Inhalte ausgewertet.

Der Job erhält automatisch neben #urN (Satznummer) und #ueD (edit date)
die Variable #uFN, die FreiRaum-Nummer, um sie evtl. bei der
Rücksendung zu verwenden mit
wri "_!_FRE" #uFN " +" n "... (danach neue Daten f. FreiRaum #uFN)
wri "_!_FRE" #uFN " -"  (Fenster unsichtbar machen, Inhalt bleibt).

Alle bisherigen Jobs mit dem "alten" FreiRaum u.a. funktionieren
damit unverändert weiter.