[Allegro] symbolische Register

[Thomas Berger]

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

Lieber Herr Eversberg, liebe Liste,

nachdem nun die Kapazitaeten frei fuer die Entwicklung von V30 sind,
folgen Desiderate fuer den Wunschzettel...

* die symbolischen (virtuelle?, Pseudo? wie ist eigentlich der offizielle
  Name?) Register werden seit einigen Versionen im Pulldown-Menue des
  Indexfensters angeboten. Bei niedrigem Zugriffslevel wurden bislang
  Register 11 und evtl. sogar Register 10 nicht angeboten, jetzt haben
  Anwender eine wesentliche Komfortsteigerung: Musste man sich bislang
  erst einmal Wissen um die Registerpraefixe aneignen, werden nun die
  einem eigentlich vorenthaltenen Daten direkt mit Erlaeuterung angeboten.

  Wg. Avanti-Anwendung und Nutzen in Flexen sind die symbolischen
  Registernamen aber fast unverzichtbar (zumindest waere es ein grosser
  Rueckschritt, nun alle Flexe auf die Notation "|;pipapo" zurueckzustellen.
  Umgekehrt gibt es einige symbolische Register, die fuer interaktive
  Anwender nicht wirklich spannend sind, da sehe ich eher das Beduerfnis,
  die Liste zu entschlacken und sinnvoll zu sortieren.

  Vorschlag: Ueber eine neue Einstellung in der .ini-Datei eine Liste
  von anzubietenden symbolischen Registern inklusive Sortierung einrichten,
  fehlt dieser Einstellung, werden weiterhin alle angeboten. Es werden
  jedoch stets jene herausgenommen, deren reales Register durch das
  access-Level verboten ist.

  [Ich bin bekanntlich nicht davon ueberzeugt, dass man eine allegro-
  Datenbank in einer a99-Umgebung gegen die eigenen Mitarbeiter
  "sichern" kann, immerhin kann man denen das Leserecht auf die nackten
  Datendateien niemals entziehen. Das heisst aber nicht, dass man ihnen
  Daten, die sie nichts angehen, auch noch fertig indexiert aufdraengen
  sollte, denn selbst im besten Fall stoert es sie beim Auge-Hand-Ansteuern
  der Elemente, die sie jeweils benoetigen.]


* Umgekehrt: In Formularen und ask-Boxen gibt es derzeit keine Moeglichkeit,
  in ein symbolisches Register zu springen, um von dort einen Wert zu
  uebernehmen, es geht nur ueber das reale Register mit seinen stoerenden,
  da stets mit einzugebenden Praefixen.
  Nicht-Ziffern (und ":", ";") hinter "|" in der .frm-Datei werden wohl stets
  als Name einer View-Datei interpretiert. Hier sollte m.E. zunaechst untersucht
  werden, ob die Zeichenkette hinter "|" der Name eines symbolischen Registers
  ist. Der Zugriff darauf sollte unabhaengig vom access-Level gewaehrleistet
  sein, in diesen Auswahl-Situationen kann man sich nicht aus dem "gelben"
  Indexmodus befreien, es wird einem daher nur eine Liste etwa von Ausleiher-
  namen geboten, die man fuer eine ALFA-artige Ausleihe unbedingt benoetigt,
  ohne die Moeglichkeit weitere Daten einzusehen.

* Im Zusammenhang mit der Registermaskerade gibt es einige zu pruefende
  Unstimmigkeiten: Erfolgt der Zugriff ueber ein symbolisches Register
  und "greift" der Fussabschnitt in der .api, d.h. produziert Ausgabe,
  so funktioniert seitenweises Rueckwaertsblaettern, das Scrollen um
  eine /Zeile/ jedoch liefert den Anfang(?) des realen Registers, und man
  ist ploetzlich irgendwie "ausserhalb" des virtuellen Registers und muss
  durch Eingabe eines neuen Suchbegriffs wieder einsteigen. Bei Bedarf kann
  ich gerne einen Testfall anhand der Demo-Datenbank konstruieren.

* Anders als die Umcodierungsabschnitte ist bei der Registermaskerade
  nicht das Praefix des virtuellen Registers in #u1 enthalten. Das ist
  nicht gut, und umgekehrt waere es auch nicht gut: Es gibt einfach
  drei Faelle, die die Registermaskerade unterscheiden muss:
  1. Hauptregister und seine Aufbereitung
  2. Spezialabschnitt im Hauptregister mit spezieller Aufbereitung
  3. Spezialabschnitt mit spezieller Aufbereitung, jedoch im Kontext
     des virtuellen Registers zu praesentieren, d.h. die Aufbereitung
     muss vermeiden, das Praefix in den Ausgabetext zu integrieren, sie
     muss aber zunaechst bemerken koennen, dass sie einen Eintrag aus
     dem Spezialabschnitt verarbeitet
  Ich koennte mir vorstellen, dass hier #u2 mit dem Namen des virtuellen
  Registers belegt werden koennte, sofern der Zugriff derzeit darueber
  erfolgt. #u1 hingegen sollte (Vorschlag) analog den Umcodierungsabschnitten
  die "echte" Registerzeile enthalten, also inklusive Praefix.

* Ich nutze (insbesondere unter Avanti) in den Umcodierungsabschnitt
  eingebaute "heimliche" Hintergrundrecherchen. In einem (realen) Register,
  das /unter anderem/ Notationen enthaelt kann auch ein Verbalbegriff
  eingegeben werden (oder in einem Register mit Namen kann eine Normdaten-
  Identnummer eingegeben werden), die Umcodierung konsultiert vorab ein
  weiteres Register mit "Aufloesungen" und springt dann an diese Stelle.
  (Das Feature ist nicht unbedingt fuers Blaettern im Index interessant,
  wohl aber fuer kombinierte Suchen). Auch hier waere es hilfreich, in
  den Umcodierungsabschnitten (etwa als #u2) auf den symbolischen Registernamen
  der konkreten Recherche zurueckgreifen zu koennen, die Sache laesst sich zwar
  ueber Vergabe von Praefixen disambiguieren, die muessen dann aber bei
  "normaler" Nutzung in a99 auch stets eingegeben werden, was laestig ist
  (oder man doppelt alle Schluessel). Auch bei klassischen Mischregistern
  (Stichworte und Titelanfaenge, oder Stich- und Schlagworte) koennte man
  bei der Umcodierung in Kenntnis des symbolischen Registers andere Suffixe
  anhaengen, und damit etwa in der Demo-Datenbank gezielt nach Stichworten
  aus Zeitschriften etc. recherchieren, indem das geeignete Suffix angehaengt
  wird.

* Die Diskussion um Zugangsnummerngeneratoren neulich (und vor allem die
  dann von Ihnen gefundene sehr clevere Loesung: Das Problem war ja nicht so
  sehr das ermitteln der naechsten Nummer, sondern deren Aufbereitung in exakt
  der Form, die fuer den Index benoetigt wird) zeigte mir, dass es hilfreich
  sein koennte, analog "deposit" auf Abschnitte oder Unterprogramme in der
  .cPI-Datei zugreifen zu koennen. Eventuell geht es aber auch etwas
  sparsamer und zudem fuers Debuggen sehr nuetzlich: Ein "leerer" Find-Befehl
  (oder qrix-Befehl: mehrere Begriffe simultan stelle ich mir muehsam
  zurueckzuparsen vor), der keine Ergebnismenge zurueckliefert, sondern exakt
  die Zeichenkette, die der Umcodierungsabschnitt liefert (unabhaengig davon,
  ob es einen Treffer gibt oder nicht). D.h. im Flex gebe ich
  NonFind ZGN "91-1234" und erhalte in der iV zurueck den "realen"
  Registerwert "|9Z91-001234" oder was auch immer die Aufbereitung ist [Hoffen
  wir einmal, dass in realen Datenbanken der Aufbereitungsabschnitt fuer
  konkrete Zugangsnummern stets dasselbe liefert wie die Benutzereingabe fuer
  denselben Inhalt, bei der Demo-Datenbank gibt es z.B. Probleme mit Zugangs-
  nummern, die selbst wiederum mit "Z" beginnen ;-)].
  Das wuerde Ihre Generatoren-Loesung wirklich wasserdicht machen
  (und auch effizienter, und sogar bessser portierbar, sofern man "ZGN"
  fest mit sich selbst verabredet), haette beim Testen von Anwendungen
  /unschaetzbaren/ Wert (wenn man wuesste, wonach wirklich gesucht wird, koennte
  man auch verstehen, warum die Suche trotz richtiger Eingabe 0 Treffer liefert)
  und eroeffnet nebenbei auch eine "deposit"-artige Funktionalitaet, die etwa
  dann nuetzlich ist, wenn man auf die Umcodierungsroutinen der .cPI
  zurueckgreifen moechte.


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

iQCVAwUBSvH2+WITJZieluOzAQJBygP/SAnfZ1H3IBbBbZl3JFRv9OX0heb6wtoI
QINrHGUubMOg8PYQ2EL9P6++toNu7TJcPzB9LlIfinqGun990sLFr36IgY9wmqdL
3uWsmqMpbQOtOGsBoHAV6htEB1B51/zXsNIcUu5YlSrrpXUThOurNVjXPNruE+6a
H2yuZKw1Y18=
=Yoij
-----END PGP SIGNATURE-----