MudGuard: 2 abhängige Dropdowns - wann auf ungültige Kombination testen?

Beitrag lesen

Hi,

Es ist eine Frage der Relation, also was wovon warum abhängig ist bzw. wie die logische Folge ist. Also entweder du sagst: wähle etwas aus Dropdown1, dann hast du folgende Möglichkeiten (Dropdown2) oder umgekehrt. Mal ein Beispiel:

Also - es geht darum, für eine Tabelle mit zig Spalten und zigtausend Zeilen Filter zu definieren.
Das ganze ist so konzipiert, daß es möglichst unabhängig von der konkreten Tabelle genutzt werden kann ...
Insgesamt gibt es - neben den beiden verbunddenen Dropdowns noch 3 weitere Controls, also insgesamt 6 Teile:

1. Dropdown für die Auswahl der Spalten
2. Auswahl des Vergleichsoperators (mein dropdown1, im Bild "Operator"), das enthält: ==, <, >, beginswith, contains, endswith, matchesregex
3. Auswahl des Vergleichsverfahrens (mein dropdown2, im Bild "Modifier"), das enthält: StringCaseSensitive, StringIgnoreCase, Numeric (plus evtl. noch date)
4. Eine Checkbox zum Invertieren der Bedingung (damit kann also !=, <=, >=  usw. bewirkt werden)
5. Ein Editfeld für die Eingabe des Vergleichswertes
6. Der Button, der den Filter in die Filterliste einfügt und auf die Tabelle anwendet.

Sieht dann so aus:

beginswith, contains, endswith, matchesregex sind natürlich für numerische Vergleiche sinnlos.
Ist einer von diesen ausgewählt, sollte also bei den Vergleichsverfahren numeric wegfallen.

Umgekehrt: ist numeric ausgewählt, sind beginswith, contains, endswith, matchesregex sinnlos, sollten also wegfallen.

Ursprünglich hatte ich alles in ein Dropdown gepackt, aber das erschien mir zu unübersichtlich - 7 Operatoren für Strings mal 2 Varianten (case) mal 2 (invertiert) sind 28 Einträge, dazu noch 4 * 2 numerische, also bereits 36 Einträge.

cu,
Andreas

--
Warum nennt sich Andreas hier MudGuard?
Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.