Kein Filter auf implizite Attribute möglich (evtl. Feature Request) #456
Description
Bei Versuchen (auf Grundlage des heutigen Nightly Builds der 1.1.x), eine Hierarchisierung von Datenmodellen über die Eltern-/Kind-Beziehungen herzustellen, die direkt id und pid nutzen, ist es uns bisher nicht gelungen, eine Frontend-Liste zu erzeugen, die genau diese Attribute nutzt, um bspw. zu einem Eltern-Element alle zugehörigen Kind-Elemente in einer eigenen MetaModels-Liste anzuzeigen.
Beispiel
Es gibt drei Modelle A, B und C. Instanzen von A beinhalten Instanzen von B und letztere wiederum Instanzen von C. Es gilt also bei passendem Setup der Erfassungsmasken:
mm_a.id = mm_b.pid
und
mm_b.id = mm_c.pid
Einrichtung einer Liste
Es soll eine Liste für A im Frontend eingerichtet werden. Diese soll gefiltert werden können, bis am Ende ein Einzeleintrag aus dieser Liste als Detailansicht übrig bleibt, zu dem alle Instanzen von B mit mm_b.pid=mm_a.id in einer zweiten Liste auf der Seite gelistet werden sollen. Analog soll es dann möglich sein, auch bei Einzelanzeige einer Instanz von B die zugehörigen Instanzen aus C direkt zu listen.
Es wurden Listen ergänzt, die eine entsprechende Filter-Einstellung zur Abbildung der Eltern-/Kind-Beziehung benötigen. Zu B wurde dazu versuchsweise ein Filter deklariert, der eine einfache Abfrage nutzt. Diese Abfrage unterstützt aber nicht pid als Attribut. Deshalb wurde alternativ versucht, eine SQL-Abfrage zu definieren, die einen GET-Parameter auswertet (ist das eigentlich bzgl. SQL-Injections sicher?). Die Query war im Fall des Filters auf B
SELECT id FROM {{table}} WHERE pid={{param:get?name=a&default=-1}}
Dieser Ansatz funktionierte aber nicht, da es nicht möglich war, zuvor einen Filter für A zu definieren, der die Liste von A-Instanzen über den Query-Parameter a nach Attribut A.id filtert. FYI: In der zweiten Stufe wäre die SQL-Query im Filter der Liste von C
SELECT id FROM {{table}} WHERE pid={{param:get?name=b&default=-1}}
Nutze ich bspw. einen Filter auf A, um über ein explizites Attribut name zu filtern, dann kann ich die Eltern-/Kind-Beziehung in B nur noch über einen SQL-JOIN/Subselect filtern, da ich zwar den Wert von name in A per Anfrage erhalte, aber erst auf die id von A abbilden muss, damit ich in der SQL-Abfrage des Filters von B dann nach passenden pid-Werten suchen kann:
SELECT id FROM mm_b WHERE pid IN ( SELECT id FROM mm_a WHERE name={{param::get?name=name}} )
Dieser Weg ist aber nicht unbedingt vorteilhaft bzgl. Performance und DB-Kompatibilität. Auch ist das Formulieren von SQL-Abfragen nicht gerade für "normale Nutzer" von Contao erklärbar.
Augenscheinlich wäre es daher doch vorteilhaft, bei der Definition von Filtern direkt auch die Attribute id und pid nutzen zu können. Oder ist der Ansatz komplett falsch?