[Allegro] Kleinere Verbesserungen in acon geplant

[Thomas Berger]

Lieber Herr Eversberg,

> Im a35-Kontext fiel uns auf: acon kennt die Befehle  first r, next r, last r,
> prev r  nicht. Damit kann a99 eine Erg.Menge abarbeiten, ohne
> die Datensätze zu laden - nur die Kurzzeilen aus der .STL werden dazu
> genutzt.
> Für a35, aber auch für andere Web-Schnittstellen wäre es von Vorteil,
> zur Präsentation einer Ergebnis-Kurzliste nicht die Datensätze komplett
> laden zu müssen, sondern dazu eben die Kurzzeilen zu nutzen.

Trunkiertes halte ich in der Praxis fuer inakzeptabel. Bzw. acon kennt
ja "list" - da braucht man nicht selber durch die Ergebnismenge zu hoppeln.


> Sicher, mit Hilfe der Datensätze kann man eine Kurzliste aus mehr und
> anderen Feldern komponieren (in a35erg.job mit a35erg.apr), und das hat
> ja auch seinen Reiz. Wir wollen trotzdem die Alternative ermöglichen,
> dafür die .STL zu nutzen, wenn sie sich dazu gut eignet. In a30 war es
> ferner nicht schwer gewesen, die auf solcher Basis errichteten
> Erebnismengen dann auch im Browser zu sortieren nach den in der STL
> vorhandenen Tabellenspalten. Ferner kann a30 Erg.Mengen kombinieren.
> Ob wir alles das in a35 bald nachvollziehen können, bleibt zu prüfen -
> statt die Ergebnismenge mehrfach vom Server abzurufen und jeweils
> anders sortiert liefern zu lassen, also avanti weit mehr zu beanspruchen
> als a30 das brauchte.

In der Tat nutze ich in Web-Anwendungen die .STL primaer dazu, um
Ergebnismengen zu sortieren, z.B. bei "qrix title+", wo acon ja
keine Sortiermoeglichkeit anbietet bzw. in den (=allen) Situationen,
wo eine gestufte Sortierung nottut: Mangels Notation kann man
acon ja nicht angeben, wonach wirklich zu sortieren ist (etwa nach
Verfasser (Pos. 48-65) gefolgt von Titel (Pos. 1-47) als sekundaerem
Kriterium: Hier ist eine Verbesserung dringend notwendig (und seit
1997 oder so durch die Entwicklungsabteilung vage versprochen)


> Zunächst also wollen die Befehle  first r  etc. endlich realisiert
> werden.
> Eine wichtige Frage dabei: Gebraucht wird neben der Kurzlistenzeile
> dann auch die interne Satznummer. Wenn man also sagt: next r, dann
> soll nicht nur die Kurzzeile in der iV stehen, sondern die spezielle
> Variable i soll die zugehörige Satznummer enthalten. In a99 ist das
> der Fall. Der aktuelle Datensatz mit seiner internen Nummer soll
> davon natürlich unberührt bleiben! Sie steht in der Variablen
> rNr des RECORD-Objekts und das muß sein, damit er korrekt gespeichert
> wird, falls das danach erfolgen soll.

... und die Erwartung ist, dass "var i" seine Nummer angibt. Das
passt doch nicht zusammen?



> Ein anderer Unterschied ist aufgefallen:
> 
> find #nnn
> 
> lädt a99 den Satz mit der internen Nummer nnn, ohne daß sich an der
> aktuellen Erg.Menge etwas ändert.
> 
> acon dagegen fügt diese Nummer der aktuellen Ergebnismenge hinzu, ohne
> den Satz zu laden.
> (Die Erg.Menge besteht intern aus nichts als einer Nummernfolge im
> Arbeitsspeicher. Bei a99 steht sie in einer Datei, z.B. cat._1)
> 
> Um dasselbe wie in acon, also Hinzufügung zur aktuellen Erg.Menge, in
> erreichen, muß man für a99 schreiben:
> 
> find or #nnn
> 
> Dagegen lädt
> 
> f1nd #nnn
> 
> auch in acon den Satz und macht ihn zum aktuellen Satz.
> 
> Das ist nicht besonders intuitiv, aber jede Änderung könnte
> Fehlfunktionen in existierenden Jobs und FLEXen provizieren.
> Oder sieht jemand Verbesserungsbedarf oder gar -möglicheiten?

Meine "avanti"-Jobs enthalten stets eine Konstruktion mit Spatium,
find # nnn,kkk,...

Gibt es einen Unterschied zwischen
find #nnn
und
find # nnn

viele Gruesse
Thomas Berger