yakamara / redaxo_yform_docs

Dokumentation für YForm
31 stars 30 forks source link

Table Manager: be_manager_relation - Filter? #3

Closed alxndr-w closed 3 years ago

alxndr-w commented 8 years ago

Bräuchte Beispiele, wie man "Filter" richtig anwendet. Ist damit die WHERE-Klausel gemeint?

dergel commented 8 years ago

die Filter sind eine gute Frage, weil ich diese auch nicht richtig weiss. Gregor ist da fitter.. ich schicke ihm das issue

gharlan commented 8 years ago

Es ist quasi die WHERE-Klausel, wobei man keine SQL-Syntax schreibt, sondern eine eigene. Pro Zeile wird ein Filter notiert. Die Filter werden quasi mit AND verknüpft, OR gibt es nicht. Auch gibt es bisher nur Filter der Form a = b, keine anderen Vergleichsoperationen.

Beispiel: News-Tabelle mit Relationsfeld category_id, und somit auch eine Kategorie-Tabelle.

  1. In der Kategorie-Tabelle gibt es ein Feld status. Nun soll man in der Newstabelle nur Online-Kategorien auswählen können. Dann trägt man dies als Filter ein:
    status = 1
    Links vom Gleichheitszeichen steht immer ein Feld aus der "anderen" Tabelle (Kategorien), rechts ein Vergleichswert.
  2. Angenommen es gibt noch eine Oberstruktur "Projekte", denen die News und Kategorien zugewiesen sind. Nun soll man nur Kategorien auswählen können, die im selben Projekt (project_id) sind, wie die News selbst. Dann kann man folgenden Filter setzen:
    project_id = ###project_id###.
    Wie gehabt, links ein Feld aus der anderen Tabelle, rechts ein Vergleichswert. Wobei man dort auch eine Spalte aus "dieser" Tabelle (News) nehmen kann, indem man die Rauten um den Feldnamen setzt.
  3. Links wie rechts können auch Referenzen zu Spalten in anderen über Relationsfeldern verknüpften Tabellen gesetzt werden. Nehmen wir an es gibt eine Tag-Tabelle, und für die Tags gibt es noch mal eigene Tag-Kategorien. Bei den Projekten kann man auswählen, welche Tag-Kategorie in dem Projekt zur Verfügung stehen soll. In den News soll man also nun Tags zuweisen können, deren Kategorie die beim Projekt zugewiesene ist. Dann setzt man beim Relationsfeld tags folgenden Filter:
    tag_category_id = ###project_id.tag_category_id###
    Links steht das tag_category_id-Feld aus der Tags-Tabelle, rechts eine verschachtelte Referenz, im über die project_id zugewiesenen Projekt das Feld tag_category_id. An der Stelle sind beliebig tiefe Verschachtelungen möglich, zum Beispiel ###project_id.tag_category_id.status### etc.
    Nun ändern wir es so, dass nicht im Projekt eine Tag-Kategorie ausgewählt wird, sondern umgekehrt, in der Tag-Kategorie wählt man ein Projekt aus. Und nun soll man also nur Tags auswählen können, bei denen das Projekt der Kategorie dem Projekt der News entspricht. Dann setzt man folgenden Filter:
    tag_category_id.project_id = ###project_id###
    Links sind keine tieferen Ebenen bisher möglich.

Einerseits sind die Filter also schon ganz schön mächtig (Verschachtelungen etc.), gleichzeitig aber auch sehr eingeschränkt (kein OR, kein >, < etc.). Intern wird je nach Relationstyp recht unterschiedlich mit den Filtern umgegangen (weshalb es auch nicht in SQL-Syntax geschrieben wird). Bei den "Multiple 1-n"-Feldern öffnet sich zum Beispiel ein Popup wo dann oben die Filter angezeigt werden, und wenn man neue Einträge erstellt, sind dann die Felder entsprechend den Filtern festgesetzt.

Nun stellt sich mir die Frage, ob das ansatzweise verständlich ist, und wie wir das in die Doku verpacken?

alxndr-w commented 8 years ago

Nun stellt sich mir die Frage, ob das ansatzweise verständlich ist, und wie wir das in die Doku verpacken?

Also zumindest ist es ausführlich, wofür ich mich erstmal bedanken möchte. Ich habe es gerade nur überflogen, aber es scheint auch (mir) verständlich zu sein und ich würde mir Gedanken machen, wie man das noch erklären kann. Im Prinzip ist be_relation schon so mächtig, dass ich gerne eine eigene Unterseite mit Szenarien dafür gesehen hätte. Da würde das gut reinpassen.

Grundsätzlich könnte man natürlich schon hinterfragen, ob es nicht sinnvoller wäre, da auch SQL reinschreiben zu können (bei Nicht-Popups bspw., wodurch viel Erklärung wegfallen würde) oder zumindest andere Operatoren verwenden zu können. Aber das ist ja hier in der Doku nicht die Frage.

PS: ich bezweifle, dass das irgendjemand außer bei euch im Haus je voll ausgenutzt hat. Umso besser, wenn es nun dokumentiert ist.

gharlan commented 8 years ago

PS: ich bezweifle, dass das irgendjemand außer bei euch im Haus je voll ausgenutzt hat.

Bezweifle ich auch. Vor allem, weil es ja kaum einer wissen kann, wie man die Filter nutzt, wenn es keine Doku gibt. ;) (Bei der letzten xform-Schulung hatte ich es erklärt)

Auch wir nutzen die bisher so richtig nur in einem Projekt, für das sie auch entstanden sind (unter Zeitdruck). Und dort brauchten wir in erster Linie die Variante, wo SQL-Syntax nicht möglich wäre.

tbaddade commented 6 years ago

Fehlt scheinbar noch in der aktuellen Doku oder?

ynamite commented 4 years ago

Eine Frage zu diesen Filter, funktionieren die auch mit Relationstabellen (many to many)?

Ich habe folgendes Szenario: Tabelle rex_betrieb Felder: name | berufe | ansprechperson_1 | ansprechperson_2 Tabelle rex_beruf Felder: name Tabelle rex_beruf_zu_betrieb Felder: id_betrieb | id_beruf

Unter rex_betrieb habe ich ein be_relation Feld als Multiselect (Feld A) wo ich einem Betrieb verschiedene Berufe zuweisen kann. Soweit so gut.

Da jeder Betrieb bis zu 2 Ansprechpartner haben kann, soll's in der gleichen Tabelle, am Ende, ein weiteres be_relation Feld geben, welches nur die Berufe enthält, die im Feld A zuvor ausgewählt (und gespeichert) wurden. Die Idee ist, dass man einstellen kann, welche Ansprechperson für bestimmte Berufe zuständig ist.

Nun dachte ich, dass man über das be_relation-Filter-Feld die Auswahlmöglichkeiten entsprechend eingrenzen kann.

Folgend die Einstellungen (nur relevante Felder) für ansprechperson_1 (be_relation Feld) welches ich unter rex_betrieb angelegt habe:

Feld Wert
Name ansprechpartner_1
Ziel Tabelle rex_beruf
Ziel Tabellenfelder name
Mehrfachauswahl select (Multiple)
Relationstabelle rex_beruf_zu_betrieb
Filter id_betrieb = ###id###

Geht das überhaupt? Und falls ich damit nicht total auf dem Holzweg bin, wie? Ich hoffe ich habe mich verständlich ausgedrückt, sonst bitte Bescheid geben. Danke für die Hilfe

gharlan commented 4 years ago

Ich muss gestehen, dass ich bei deinem Beispiel noch nicht wirklich durchblicke. Unter anderem weil du unten schreibst, es würden die Einstellungen des Felds ansprechperson_1 folgen, und dann folgt aber die Definition des Felds berufe.

Aber was ich sagen kann: Es geht bisher nicht, ein Feld dynamisch zu filtern entsprechend der Auswahl in einem Feld weiter oben, also im selben Formular. Sondern es sind bisher nur Fälle umgesetzt, wo die Einschränkung (Filter) bereits feststeht, wenn man das Formular öffnet.

ynamite commented 4 years ago

@gharlan hoppla, sorry, war evtl. verwirrend. Das Feld ansprechperson_1 hat den Namen berufe (weil ja Berufe eingetragen werden. Mein Fehler sorry!). Sprich berufe = ansprechperson_1.

Es geht mir nicht darum dynamisch zu filtern, schon klar dass das nicht geht. Ich möchte also nicht-dynamisch filten :) Das Formular bzw. der Datensatz wird zuerst vom User gespeichert und erst danach, nach erneutem Aufruf, soll das Feld nur Datensätze enthalten wo id_betrieb gefiltert ist (sprich wo id_betrieb = ###main_id### bzw. data_id).

gharlan commented 4 years ago

Also es tut mir Leid, aber ich blicke nicht durch, und kann es dir daher im Konkreten nicht beantworten, ob das nun geht oder nicht.

Oben schreibst du es gäbe die Felder berufe, ansprechpartner_1 und ansprechpartner_2, jetzt sagst du berufe = ansprechpartner_1. ansprechpartner_1 ist vom Namen her ein Single-Feld, und auch dass es ja noch ansprechpartner_2 als weiteres Feld gibt, spricht für Single-Feld. In deiner Felddefinition steht aber, es wäre ein Multiple-Select mit Relationstabelle. Irgendwie alles nicht ganz stimmig ;)

Ggf. kannst du deinen Fall als kleines Tableset rauslösen, sodass man es bei sich importieren kann?

Ansonsten nochmal zwei wichtige Parts aus meinem langen Erklärtext oben zu den Filtern:

ynamite commented 4 years ago

Vergiss bitte was ich vorher geschrieben habe, nochmal von vorn:

  1. in der Tabelle rex_betrieb wird ein Datensatz editiert
  2. im Multi-Select betrieb_berufe (be_relation -> rex_beruf) werden mehrere Berufe gewählt und der Datensatz anschliessend gespeichert. Ein weiteres Feld, ansprechpartner (ebenfalls Multi-Select be_relation) ist hier noch leer.
  3. Datensatz wird erneut zum Bearbeiten aufgerufen
  4. nun soll das Feld ansprechpartner nur die im Feld betrieb_beruf zuvor gewählten Datensätze anzeigen (um das geht's mir), so dass man hier nun eine Auswahl aus den bereits gewählten Berufen treffen kann.

Problem: ich krieg das Feld ansprechpartner nicht "gefiltert" auf die ID (yform data_id) des Betriebs gefiltert.

tbaddade commented 4 years ago

@ynamite Das heißt, dass jeder Ansprechpartner auch eine Relation zu den Berufen hat? Und im Datensatz einen Betriebes willst du nur die gefilterten Ansprechpartner anhand des Berufes erscheinen lassen?

ynamite commented 4 years ago

Fast :) Ansprechpartner soll eine einfache Relation zu Berufe/Betriebe haben. Gefiltert auf die ID des Betriebs. Ein Betrieb kann mehrere Berufe haben, die dann einem Ansprechpartner zugeteilt werden sollen. Siehe Struktur in meine ersten Post hier, ganz oben.

Falls noch immer nicht klar kann ich sonst mit Screenshots nachhelfen.

tbaddade commented 4 years ago

Falls noch immer nicht klar kann ich sonst mit Screenshots nachhelfen.

Um weitere Missverständnisse auszuräumen, wären Screenshots und ein Export / Tableset sicherlich hilfreich :)

gharlan commented 4 years ago

Ich glaube, ich habe deine neue Erklärung nun einigermaßen verstanden, und befürchte, dass das so noch nicht geht, wie du es willst. Ganz sicher bin ich mir aber nicht.

ynamite commented 4 years ago

Hier noch ein Screenshot zur Erklärung: grafik

@gharlan Das dachte ich mir. Werde es entweder mit einem Choice-SQL oder einem Custom-Feld lösen. Danke trotzdem und sorry für die Verwirrung, Erklärungen schreiben gehört offensichtlich nicht zu meinen Stärken.