[Allegro] HFM : Neue Lösung, a99-Prototyp zum Testen

[Bernhard Eversberg]

Am 23.06.2014 08:50, schrieb Thomas Berger:
>
>> o  Ältere Programme können damit nicht umgehen, sie lassen beim
>>     Einlesen eines derartigen Satzes nur das letzte Feld mit dem .
>>     übrig!
>
> [Wir sollten bei Gelegenheit ueber einen Mechanismus nachdenken,
> der "alte" Programme zum Ausstieg zwingt, wenn eine Datenbank
> ein Feature ~nutzt~, das definitiv zu neu ist]
>
Wobei in diesem Fall das Feature beim Start gar nicht zu
erkennen ist - die CFG oder die Indexparameter werden dazu
nichts aussagen! Das gehört ja mit zur Lösung, daß man NICHTS
erst konfigurieren oder parametrieren muß, um HFM zu nutzen!

>>
>> o  Die Zahlen müssen nicht lückenlos aufeinander folgen.
>>     Daher könnte man Nummern auch mit einer Semantik ausstatten.
>
> Bitte nicht!
>
Das *empfehlen* wir auch nicht: Der Satz steht im Konjunktiv. Es *mag*
aber hier und da auch mal sinnvoll sein, und warum sollen wir das
vom Entwurf her abwürgen oder Gefahren an die Wand malen, die dann
drohen würden - die es technisch aber nicht gibt? Im Zweifel für
die Freiheit.

> Vielmehr sollte angekuendigt werden, dass in zukuenftigen Versionen
> evtl. "Einfuege"-Funktionen angeboten werden koennten, die dann natuerlich
> zu einer teilweisen Umnummerierung fuehren.
>
Sicher, das ist eine denk- und wünschbare Erweiterung.

>
> o  Mit  var #nnn~  erhält man in FLEX das letzte der Mehrfachfelder
>     des Feldes #nnn - wie schon bisher
>
> Mit oder ohne Nummer?
>
Momentan mit. Können Sie leicht feststellen. Ist aber inkongruent mit
dem Fall der normalen Wiederholungsfelder udn sollte daher nochmal
überdacht werden.

> In der Exportsprache ist es ein unglaublicher Akt, das letzte vergebene
> Fortsetzungszeichen zu ermitteln,
Das müssen wir uns sowieso noch anschauen, ist noch gar nicht
realisiert.


>
> Ja. Mir Unlieb, aber leider erforderlich ist die Nutzung von #uY~ und
> #uZ~ fuer Flips. Dafuer laesst sich aber mittelfristig vielleicht
> ein alternativer Mechanismus einfuehren,
Ganz anderes Thema.

> Vorhandene Konstrukte
>
> #98. ++ ...
>
> sollten eigentlich durch die Ergaenzung
>
> #98. ++ f"0123456789 " ...
>
> ~halbwegs sauber~ gerettet werden koennen. "Richtig sauber" wird
> es dann, wenn f"0123456789 " nur dann ausgefuehrt wird, wenn der
> Folgebuchstabe ein "." ist, Indikatoraktionen koennen hier testen,
> wuerden aber die "++"-Iteration vorzeitig beenden. [Es fehlt eigentlich
> seit jeher eine Schleifenkonstruktion, die trotz fallweiser Abbrueche
> stets und unbedingt alle Wiederholungen durchlaeuft...]
>
Richtig, das wäre bei der Gelegenheit mal zu prüfen.

>
>> -  Bei Eingabe von  #nnn.~ xyz  hätte man gerne folgendes noch nicht
>>     realisiertes Verhalten:
>>     Es wird die letzte #nnn.zzz gesucht und auf die Zahl dann 1
>>     aufaddiert, um die nachfolgende HFM-Kennung zu bilden.
>
>
> [Vermutlich noch nicht behandelt sind die "+"/"-"-Buttons in Formularen?
> Die brauchen vermutlich manchmal syntaktische Nachhilfe um zu wissen,
> ob sie mit A-Z oder .1 - .ultimo zaehlen sollen]
>
Sicher, aber die Formulare sind für hochfrequente Mehrfachfelder sowieso
keine ganz glückliche Lösung. Da ist externe Editierung sicher für viele
Fälle die bessere Wahl.

> (falls man allerdings vor lauter Begeisterung innerhalb derselben Kategorie
> desselben Datensatzes einen Mix aus klassischen Folgebuchstaben und neuen
> HFM-Wiederholungen nutzt, geht eine schematische Umsetzung nicht mehr
> bzw. nur anders - da sollte man sich bei Eingaben also zurueckhalten, auch
> wenn es naheliegt, nach "Z" oder "z" ganz "spontan" mit ".1" oder ".100"
> weiter zu machen)
>
Hier gilt die Freiheit - und Verantwortung - der Wahl.

B.E.