[Allegro] Bemerkungen zur Volltextsuche

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

>> 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.

Schon klar, dass ftr.inc nicht alleine lauffaehig ist.
Ebenso klar allerdings, dass sich 90% des Codes aus ftr.inc in ftr.flx
wiederfinden und der Kommentar
  Sprung hierher aus ftr.flx
eine Verbindung behauptet.


>> 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.

Es gibt da die Passage in ftr.inc:

  Korrektheit des regEx checken mit beliebigem Text
var "abcxyz"
srx

und anschliessend muesste m.E. ein "if" auf das "checken" reagieren...


...

>> 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.

Anders als bei #u!! wird eine Vorbesetzung von #u!D von ftr.inc
nicht beibehalten.



>> 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 stelle mir vor, dass in Situationen, wo die v14-Aufloesung echt
unerwuenscht ist, die Gross/Klein/Sonderzeichen-Egalisierung des
Suchbegriffs verzichtbar bis ebenfalls unerwuenscht ist.

Es bleiben die Situationen, wo man eine "normale" Volltextsuche in
Feldern durchfuehrt, von denen man weiss, dass sie nicht von v14-
Ersetzungen tangiert werden, Auslassen der Ersetzung also eine
Beschleunigung bringen kann: Das Resultat ist dann allerdings dasselbe
und es ist die Frage, ob man allen Benutzern zumuten soll, eine
schwer verstaendlich zu formulierende Zusatzfrage zu beantworten oder
einigen, einen schnelleren Rechner zu kaufen oder etwas laenger aus
dem Fenster zu schauen.


> 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?

Wenn ich eine Konstruktion

... if $v14 if v14 ...

lesen muesste, wuerde ich zunaechst an einen Editor-Unfall denken.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAk26ZcEACgkQYhMlmJ6W47NL5gP7BgA/9vQSw10h3n19DIMkQiGH
781DO4VT1J3rQo/zfQNqpmzCR28R+T/py0ZwrIaV1Z/IonLbE9HPL2cBXagj5BIA
b3aaNvO+xfbJULqjZaFn+Vm1Od59zr/8GTWAO5ATGb0Z9ngX5TIz02z+sb9Nkt54
6Q3NjyYoVpFeeZAh6nw=
=q4Qs
-----END PGP SIGNATURE-----