search

rowe42 / lhm_animad_admin_html5

0 stars 6 forks source link

Festlegung der Syntax für Suche in Listen #191

Open Dr-Thomas-Tensi opened 6 years ago

Dr-Thomas-Tensi commented 6 years ago

Für die Suche in unseren Listen gibt es bereits eine Basisimplementierung, die im Wesentlichen die Suchsyntax aus GitHub nachbildet.

Es sind per Leerzeichenfolgen getrennte Folgen von jeweils durch Doppelpunkt getrennten Schlüssel-Wert-Paaren. Ein Wert darf auch in Doppelapostrophen eingeschlossen sein, damit man Sonderzeichen als Wertbestandteil angeben kann (insbesondere Leerzeichen).

Diese Syntax klappt bei GitHub gut, weil dort die Schlüssel immer Worte sind; bei uns ist aber die natürliche Syntax oft eine Nominalphrase mit Leerzeichen (z.B. "Name des Geheges").

Das ließe sich auch wieder mit Quoting auflösen, aber dann wird die Syntax unhandlich. Insbesondere gibt es auch weitere Anforderungen an die Suchsyntax wie z.B. liberale Leerzeichensetzung, ODER-Junktor, Wildcards, Klammerung usw., die die Komplexität der Eingabe (und Verarbeitung ;-) nach oben treiben.

Ich biete an, eine vollständige Syntax zu überlegen, mit Euch abzustimmen und die JavaScript-Frontend- und Java-Backend-Implementierung dazu zu machen.

Meinungen?

ejcsid commented 6 years ago

@xdoo @dragonfly28 @rowe42 @Baumfrosch @ejcsid

Dr-Thomas-Tensi commented 6 years ago

Erste Überlegungen zur Suchsyntax in der Referenzarchitektur

Grammatik

-- TOKENS --
lParToken ::= "(" .
rParToken ::= ")" .
stringToken ::= <<single or double quote surrounded char sequence
          optionally ending with "*">> .
wordToken ::= letter { letter | digit } .
orToken ::= "|" | "oder" .
andToken ::= "," | "&" | "und" .
notToken ::= "!" | "nicht" .
starToken ::= "*" .

-- Problem bei den Junktoren: deutsche Namen können auch als
-- Bestandteile von Schlüsseln oder Werten vorkommen, dann gibt es
-- Namenskollisionen ==> ggf. diese Varianten der Token weglassen

-- PRODUCTIONS --
primaryExpression ::= stringToken | keyValuePair | notToken primaryExpression
          | lParToken expression rParToken .
keyValuePair ::= wordList equalsSymbol value .
wordList ::= wordToken { wordToken } .
value ::= literal | wordList [ starToken ] .
literal ::= booleanToken | numberToken | dateToken | stringToken .
term ::= primaryExpression [ andToken term ] .
expression ::= term [ orToken expression ] .
AXIOM ::= expression .

Pragmatik

Anfrage an Backend

xdoo commented 6 years ago

Diese Syntax klappt bei GitHub gut, weil dort die Schlüssel immer Worte sind; bei uns ist aber die natürliche Syntax oft eine Nominalphrase mit Leerzeichen (z.B. "Name des Geheges").

Das verstehe ich nicht. Ist es nicht so, dass die Suche bei uns immer im Kontext einer Entität statt findet? D.h. wenn ich ein Gehege mit einem bestimmten Namen haben will, dann brauche ich doch nicht "des Geheges".

Bevor wir hier Aufwand rein stecken, fände ich es hilfreich zu verstehen, warum wir das brauchen. Die Behauptung, dass die natürlich Syntax oft eine Nominalphrase ist, hilft mir da nicht weiter.

Dr-Thomas-Tensi commented 6 years ago

Ist es nicht so, dass die Suche bei uns immer im Kontext einer Entität statt findet? D.h. wenn ich ein Gehege mit einem bestimmten Namen haben will, dann brauche ich doch nicht "des Geheges".

Du hast vollkommen recht, dass der Kontext eigentlich klar ist. Aber wie erkennt der Nutzer einer Tabelle, dass er als Schlüssel "Vorname" oder "firstName" eintippen muss?

Die Behauptung, dass die natürliche Syntax oft eine Nominalphrase ist, hilft mir da nicht weiter.

Lass mich das ausführen, weil ich in der obigen Beschreibung etwas zu knapp war. Damit für ihn erkennbar wird, was für Schlüssel er benutzen darf, hat er zwei gleichwertige Eingabemöglichkeiten:

Das erfordert etwas aufwändige Vorverarbeitung im Frontend, aber wäre - aus meiner Sicht - eine relativ gut bedienbare Lösung.

xdoo commented 6 years ago

Aber wie erkennt der Nutzer einer Tabelle, dass er als Schlüssel "Vorname" oder "firstName" eintippen muss?

Im einfachsten Fall aus der Nutzerdoku. Menschen die solche Suchen (neben der freien Suche) nutzen sind ja in der Regel Poweruser. Die geben heute Schlüsselnummern ein, um Dinge zu tun. Um das zu vereinfachen haben wir #181.

Oder er nimmt einfach den Text, der im Spaltenkopf steht, als Schlüssel (also "Vorname des Tieres"). Und das ist, so leid es mir tut ;-), in der Regel eine Nominalphrase. Damit man sich die Finger beim Eintippen nicht abbricht, kann man einen Präfix dieser Phrase verwenden, solange er innerhalb der Spalten eindeutig ist, also z.B. "Vorname" oder sogar nur "V".

Das ist nicht so einfach wie es sich anhört, weil der Bezug Anzeigename und Attribut ausschließlich über eine Locales Datei (die jederzeit geändert werden kann) hergestellt wird. D.h. der Anzeigename ist vollkommen willkürlich durch die Fachdienststelle gewählt.

Sollte ein Verfahren eine spezielle Suche benötigen, dann bin ich der Meinung, dass dies durch das Projekt, genau auf die Bedürfnisse der Fachdienststelle zugeschnitten, implementiert werden sollte. Wir unterstützen mit unserer Arbeit, damit Projekte bei der INDIVIDUAL Programmierung schneller und hoffentlich auch besser werden. Zu einer Individual Programmierung gehört auch, dass bestimmte Dinge individuell für einen bestimmten Fall hergestellt werden.

Dr-Thomas-Tensi commented 6 years ago

[Woher kommen Namen der Schlüssel?]

[aus der Nutzerdoku, Suchdefinierer sind Poweruser]

Naja, unser Anspruch ist ja schon, dass die Oberfläche weitgehend selbsterklärend ist. Auch als Nicht-Poweruser möchte ich schnell mal eine einfache Suche hinrotzen können, ohne in einer Dokumentation nachlesen zu müssen.

[Schlüssel könnten über die Spaltenbeschriftungen gewonnen werden]

[nicht so einfach: der Bezug Anzeigename und Attribut wird ausschließlich über eine (flüchtige) Locales Datei hergestellt]

Wir haben, wenn ich das richtig verstanden habe, noch nicht letztgültig definiert, ob die Abbildung von "Attributname" bzw. "technischer Spaltenname" im Front- oder Backend stattfindet. So etwas hängt von der Komplexität der Oberfläche ab und ob man beispielsweise ohne Backendzugriff Sprachumschaltungen zulassen will und vieles mehr.

In den meisten unserer Fälle wird die Lokalisierung - und so verstehe ich Deinen Einwurf - aber mit Hilfe einer Locales-Datei im Frontend gemacht werden, d.h. dort findet die Abbildung von technischem Attributnamen auf die angezeigten Spaltenbeschriftungen statt.

Im obigen Vorschlag hatte ich geschrieben, dass es eine Abbildungsmethode "displayedToTechnicalHeadingMap" gibt; die würde genau die Information der Locales-Datei benutzen. D.h. wir haben hier kein Wartungsproblem. Es könnte höchstens sein, dass der Fachbereich mal für unterschiedliche Spalten dieselben Beschriftungen vorsieht; dann klappt die Heuristik des obigen Algorithmus natürlich nicht mehr...

Für AdHoc-Suchen trägt der Ansatz mit der Suche mit Spaltenbeschriftungen; bei vorgefertigten Suchen, die über längere Zeit funktionieren müssen, sollten eher die technischen Namen verwendet werden: dann ist man von der Lokalisierung unabhängig.

Ich gebe schon zu, dass in meinem Vorschlag viele Verarbeitungsschritte bereits im Frontend ausgeführt werden müssen. Aber wenn ich mir das zutraue, das selbst in Javascript zu implementieren, dann kann es sicher nicht megaschwierig sein ;-)

Sollte ein Verfahren eine spezielle Suche benötigen, dann bin ich der Meinung, dass dies durch das Projekt, genau auf die Bedürfnisse der Fachdienststelle zugeschnitten, implementiert werden sollte.

Hmm, wir beide vertreten die verschiedenen Enden des Spektrums: Du bist eher für ein Gerüst, das durch den Entwickler gefüllt wird; ich bin für die Maximalgenerierung. Bei der Suche denke ich, sollten wir schon eine Engine vorgeben, damit man etwas hat, was für viele Belange taugt.

Es spricht ja nichts dagegen, diese Suche durch individuelle Lösungen ersetzen zu können.

Klingt nach Diskussion in der Gruppe oder wir treffen uns mal auf einen Kaffee?

rowe42 commented 6 years ago

Also ich finde den Vorschlag von @Dr-Thomas-Tensi sehr gut und umfassend. Und es ist ja tatsächlich im aktuellen Beispiel so, dass es bei den Enclosures eine Spalte gibt, die "Name des Geheges" überschrieben ist. Und da wüsste ich als Nutzer jetzt nicht ohne weiteres, was der technische Schlüssel im Suchfeld dafür ist.

Ich kann auch nachvollziehen, dass wir das Mapping von Spaltenüberschriften auf technische Feldschlüssel über die Information in der locales-Datei machen können.

Aber: Ich schätze das als relativ komplex ein, das zu implementieren. Das wird nix für Meilenstein 1 und meiner Meinung nach ist das auch für Meilenstein 2 schwer zu bewältigen (@ejcsid weiß hier mehr, da sie sich schon mit der Suche im Backend beschäftigt hat). Wenn du dir das aber zutraust, fände ich das nicht schlecht.

Was meinen die anderen? @Baumfrosch @ejcsid @dragonfly28

DirkGern commented 6 years ago

Wenn ich es richtig verstanden habe, setzen wir im Backend Lucene ein. Ich hätte erwartet, dass wir die Lucene-Parser-Syntax mit möglichst wenigen Veränderungen an die Oberfläche bringen. Damit hätten wir wenig Aufwand, aber die Mächtigkeit von Lucene. Konkret vermisse ich

  1. die Wildcard-Suche (*, ?)
  2. Fuzzy Search
  3. Ranges [ ]

-- Problem bei den Junktoren: deutsche Namen können auch als

-- Bestandteile von Schlüsseln oder Werten vorkommen, dann gibt es

-- Namenskollisionen ==> ggf. diese Varianten der Token weglassen

Hier würde ich wie Lucene auf Großbuchstaben setzen, evtl. in Englisch. Erspart Internationalisierung und ist man vom Outlook-Client gewohnt ;-)

Die Schlüssel würde ich auch von den Headern trennen, um flexibler zu sein. So könnte man Kürzel z.B. einführen. Sie sollten aber zu 90% identisch sein.

Ich hoffe, das hilft erstmal.