[Allegro] a99 PV-Problem

[Thomas Berger]

Lieber Herr Eversberg,

> Außerdem muß man dazu sagen, daß PV eigentlich wegen der begrenzten
> Möglichkeiten von PRESTO geschaffen wurde - es gab da kein FLEX!
> Nun aber ist es so, daß man beim Speichern einen  onput.flx  haben
> kann, der kann einiges von dem tun, was unter PRESTO eben die PV tun
> mußte. Damit wird man sich vorerst behelfen müssen, bevor wir an diese
> Sache nochmal drangehen können.
> 
> Vielleicht kann aber zunächst noch geklärt werden, was man denn unter
> a99 an PV-Aktionen wirklich für unverzichtbar hält? Statt daß wir auf
> Biegen und Brechen das dokumentierte Verhalten herstellen, wenn es
> gar nicht wirklich zur Gänze oder in der Form gebraucht wird.

Die Geschichte des aktuellen Fehlerreports beweist, dass Sie recht haben:
Kategorienverdopplung ist Benutzern zufaellig aufgefallen, und Herr
Fischer berichtete vor drei Jahren vage ueber scheinbar nicht stattfindende
PV. In a99 ist da also nicht kuerzlich etwas kaputt gegangen und dennoch
ist in all den Jahren Anwendern der PV-maessige Bruch beim Uebergang von
PRESTO zu a99 anscheinend nicht wirklich aufgefallen.

Die Programmierte Validierung ist ziemlich wichtig im Zusammenhang mit
den Spezialmodi "s" und "N" (oder n?), jedenfalls unmittelbar vor dem
bzw. waehrend des Speicherns eines Datensatzes: Hier koennen dann
gewisse Aktionen erzwungen werden (etwa die Nutzung von varianten
Identnummernmustern bei noch gar nicht geimpfter Identnummernkategorie,
wegspeichern zusaetzlicher Zeitstempel). Das wird man allerdings selten
bzw. nur als Kontrollfreak benoetigen, denn onput.flx und der frei
setzbare "PV-Flex" setzen ebenfalls an dieser Stelle an.

Andere PV-Modi sind inzwischen voellig obsolet, unter a99 gibt es
keinen wohldefinierten Zeitpunkt "Abfrageliste beendet" oder
"Satz zum Editieren geoeffnet", dafuer aber mit onnew.flx, oncopy.flx
oder selbstdefinierten Flexen viele Moeglichkeiten, solche
interessanten Stellen im Workflow zu erzeugen und mit Flexen
auszustatten.

Keinen wirklichen Ersatz fuer die PV-Funktionalitaet gibt es in einem
Bereich, den ich im Sinn hatte, als mir die aktuellen Unstimmigkeiten
auffielen: Die in einer bestimmten Gruppe von Kategorien eingesetzte
Trennzeichensyntax sollte stillschweigend normiert werden, nicht nur
weil die Anwender da uneinheitlich vorgingen sondern weil ich dafuer
gerade eine Uebernahme aus einer Viewliste eingerichtet hatte und es
daher dann ganz typisch zu einem ueberfluessigen Trennzeichen am
Feldanfang oder Feldende kommt, das moeglichst schnell und moeglichst
automatisch wieder zu entfernen war. Ein anderes Beispiele sind
URLs, egal wo im Datensatz sie vorkommen, es sollten Unterstriche
durch "%5F" oder eine andere Ersatzdarstellung ersetzt werden, damit
kein Konflikt mit der v14-Methodik entsteht.

Es gibt eine Vielzahl moeglicher Bereinigungen und feldbezogener
Pruefungen (mit und ohne Index-Zugriff) und es war schon ganz frueh
klar, dass die .api dafuer kein perfekter Ort ist: Einerseits
will man zwar, dass solche Pruefungen in (fast) jeder Situation
stattfinden und .api (oder .cfg oder uif-Datei) sind damals dabei
die einzigen "Konstanten" gewesen. Andererseits handelt es sich
oft um eher "weiche" Dinge, die die Anwender einfach einrichten
und pflegen koennen sollen, der Hilfsabschnitt in der .api ist
aber selbst fuer allegro-Verhaeltnisse besonders byzantinisch.

Im a99-Kontext hat sich da leider nicht viel geaendert: Solche
Bereinigungen und Warnungen sollen auch mit dem Benutzer interagieren
duerfen, und wegen einfacher Wartbarkeit waere etwas Flex-basiertes
weiterhin wuenschenswert. Andererseits sollen solche Bereinigungen
auch dann stattfinden, wenn die Benutzereingabe im Kontext eines
bereits ablaufenden Flexes erfolgt ist, was nicht wirklich einfach
zu realisieren ist, denn dieser Zusatzflex soll mit dem Benutzer
interagieren, aber nicht mit dem laufenden Flex interferieren,
man wuerde also eine Art unabhaengige, parallele Flex-Laufzeit-
umgebung ersinnen muessen, denn mit dem ueblichen Desiderat, dass
Flexe aus Flexen her aufrufbar sein sollten, ist es hier m.E. nicht
getan.

Ich halte das Thema Feldgebundene automatische Makros allerdings fuer
wichtig genug, um es in gebotener Breite auf der Agenda zu halten:
Der Uebergang von "Abtippen oder einkopieren aus dem Index" (PRESTO)
zu "Copy & Paste ist moeglich" (a99) ist ja nicht die Endstation
und ein moeglichst FLEXibler Mechanismus zum Vorlegen moeglicher
Eingaben und Herbeiholen externer Inhalte waehrend der Benutzer
tippt wird als Desiderat m.E. immer bedeutender.

viele Gruesse
Thomas Berger