[Allegro] Bemerkungen zur Volltextsuche

[Bernhard Eversberg]

Am 28.04.2011 19:45, schrieb Thomas Berger:
> I.
>
> ftr.inc scheint vorbereitet, um die eigentliche Arbeit von ftr.flx
> zu uebernehmen (analog rsfsr.flx /rsfsr.inc oder dem Demo alldata.inc?),
Es ist umgekehrt, ftr.inc ist aus ftr.flx heraus entstanden,
und zwar wurde es herausgelöst, um einen Einbau der Volltext-
suche über die Gesamtbank auf möglichst knappe Weise in jeden
eigenen FLEX zu ermöglichen. Siehe Trick 33, auf den ftr.inc
selber hinweist.
> Das scheint mir allerdings noch etwas unfertig, anscheinend gab es
> logische Probleme, wo denn nun die Auswahl der Dateien und die
> Eingabe/Abwandlung des Suchbegriffs erfolgen soll.
Eben nicht, es ist geradezu so gedacht, daß hier kein solcher
Eingriff antizipiert wird, sondern der Ablauf total voll-
automatisch laufen soll. Wer Interaktion will, nutzt eben
ftr.flx.

> Konkret:
> ftr.inc testet zwar Korrektheit des Suchbegriffs, reagiert aber nicht
>      auf das Ergebnis
Es testet bei *Änderung* während der Laufzeit, nicht bei der
ersten Eingabe. Die würde im aufrufenden FLEX erfolgen und
hätte dort geprüft zu werden, wie es in ftr.flx zu sehen
ist. Vielleicht sollten wir es aber so machen wie im Fall
rsfsr.flx/.inc, das ist noch zu prüfen.

> ftr.inc erlaubt Abaenderung des Suchbegriffs, hat also doch die
>      gesamte Eingabelogik aus ftr.flx
Das hätte man auch herausnehmen können, wenn man streng ftr.inc
nur als vollautomatisches UP ansehen wollte. So ermöglicht es
dem FLEXperten dann immer noch den manuellen Eingriff in ein
laufendes Verfahren.

> ftr.inc belegt die Dateiliste (abweichend durch ";" getrennt statt durch
>      CRLF) mit allen .ald-Dateien aus dem Datenverzeichnis vor.
ftr.flx bietet die durch CRLF getrennten Daten zuerst als
Auswahlliste aresqa.lst. Diese liest es nach Bearbeitung ein
und trennt die Namen dann in  #u!D  mit ;, wie ftr.inc.

> Ich weiss jetzt nicht, wie gut sich ein "Abbruch" in einer interaktiven
> Anfrage nach einem "return" noch testen laesst,
Was soll denn das für ein Abbruch sein und warum? Es geht ja
dann sofort los, aber testen kann man immer noch mit
keychk, wie es in ftr.inc und ftr.flx geschieht.

> II.
> ftr.flx erzwingt v14-Ersetzungen, in ftr.inc ist die entsprechende
> Zeile auskommentiert (jeweils mit dem Hinweis, dass man am Flex
> herumschrauben koenne, wenn man anders suchen moechte).
Na ok, man könnte das durch geeignetes Setzen eines Flags im
aufrufenden FLEX steuerbar machen, wie Sie das ja dann vorschlagen,
und wir überlegen das nochmal: (Allerdings kann's auch sein, daß
der Suchbegriff nicht mit _ beginnt und trotzdem keine V14-Auflösung
gewünscht ist!)

> Ich koennte mir folgendes vorstellen:
>
> Ein Unterstrich "_" als erstes Zeichen in #u!! hat bereits eine Spezial-
> bedeutung fuer das srx-Builtin (der eingelesene Datensatz wird vor
> dem Test nicht der mittels "set x..." definierten Umcodierung unterworfen).
> Wenn man auch in ftr.flx/ftr.inc (vgl. auch rsfsr.* - wer denkt sich
> eigentlich diese Namen aus ;-(  nun ebenfalls darauf testet:
>
> var #u!!
> if "_" var ""
> ins $ftr:v14
>
> und diese Variable $ftr:v14 zur Steuerung der Ersetzung mit heranzieht
>
> if $ftr:v14 if v14 if %_% set obj 2;new 0;ins;dow R;var kn;erase;set obj 1
>
> dann hat man m.E. in vielen typischen Faellen das gewuenschte Verhalten,
> ohne den Benutzer mit einer zusaetzlich vorgeschalteten Frage nach
> "Ersetzungsmodi" unnoetig zu behindern oder zu verwirren.
Der Name "rsfsr" ist ein Akronym und ist in rsfsr.flx erklärt.
Ein Schelm, wer anderes und vollkommen unpassendes dabei denkt.
Mich dagegen befremdet Ihre Neigung zu unnütz schwülstigen
Variablennamen. (Aber gut, XML-Freunde schreiben sich gerne
die Finger wund.) Wozu $ftr:v14, wo $v14 reichen würde?
"Kleine" Variablen sind doch völlig impersistent!

B.E.