Auswahl-Optionen eines Frontend-Filters eingrenzen

Ich habe in der tl_member ein eigenes Mehrfachauswahl-Feld "Bevorzugte Marken" (brands_liked), welches das Attribut "Marken" (brands) meines MetaModels "Produkte" (mm_products) mit der ID als Schlüssel referenziert.

Nun möchte ich, dass diese Marken-Präferenzen eines angemeldeten Mitglieds die entsprechende FE-Produkt-Liste vor-filtern, so, dass dann natürlich auch die verfügbaren Optionen des dort bereits eingebauten Einzelauswahl-Filters "Marken" auf diese vor-definierten Präferenzen begrenzt sind.

Lässt sich das direkt über die MM-Filter-Settings lösen? Und wenn ja, wie am elegantesten?

Danke für einen Rat.

Gruß, Hendriks

Oder geht das nur / am besten über's Template?

Major Tom an MetaModel-Erde: "Noch jemand da? Oder alle vom 3.0-Wurmloch verschluckt?" :rolleyes:

Oder aber –was ich auch nicht ausschließen möchte– saublöde, unnötige Frage von mir... :( :D

Hallöchen!?

War meine Frage (seit langem mal wieder) zu blöd? Oder ist die Antwort zu offensichtlich? :rolleyes:

Vielleicht stehe ich grade (mal wieder ; o ) etwas auf dem Schlauch!? Um so wichtiger wäre mir deshalb aber ein kleiner Griff unter die Arme von jemandem der mit so etwas bereits Routine hat!

Danke...

So richtig blicke ich auch noch nicht durch. Du willst, dass sobald ein Mitglied angemeldet ist, es nur noch seine Favoriten Marken sieht. Richtig?
Sobald Du einen Filter laufen hast für das beschriebene Szenario, sollten die weiteren Filter eh eingegrenz sein.

Hallo Tim,

na ja, die Frage bezieht sich dann wohl vielmehr darauf, wie das entsprechende Filter-Setting dazu aussehen müsste!?

Ich habe also folgendes:

Eine Seite "Produkt-Empfehlungen" für angemeldete Mitglieder, mit einer entsprechenden MM-FE-Produkt-Liste und einem MM-FE-Produkt-Filter.

Der MM-FE-Produkt-Filter besteht bis jetzt aus den folgenden aktiven Komponenten: einer Prüfung des "Veröffentlichungsstatus", sowie einer Reihe von "Einzelauswahlen", damit sich das Mitglied die (im Ziel, also im Moment noch nicht vorab für ihn nach eigenen Marken-Präferenzen vorgefilterte) Liste nach Bedarf weiter runter-filtern kann...

Ich vermute, dass ich nun wohl lediglich eine weitere Filter-Komponente (wohl tunlichst vor den Einzelauswahlen!?) vom Typ "eigenes SQL" in den Filter einfügen muss.

Dazu wäre dann wohl "nur" noch meine Frage: Wie muss das SQL hier lauten / wie muss die SQL-Syntax aussehen, wenn ich die Produkte nach denen in der tl_member gesetzten [brands_liked] (Mehrfachauswahl, Feldtyp: BLOB) filtern möchte?

EDIT: Und am besten natürlich so, dass, wenn keine bevorzugten Marken (im Vorfeld) gesetzt wurden (also die Spalte brands_liked leer ist, dass dann alle Produkte (Marken) angezeigt werden...

Ich kenne das halt bisher "nur" aus PHP in folgender Art (in etwa) — mit dem Zwischenschritt einer PHP-Variablen:

PHP-Code:

$thisUserPreferences = $this->Database ->prepare ("SELECT brands_liked AS brands_liked FROM tl_member WHERE username = ?") ->execute ({{user::username}}); $thisUserRecommendations = $this->Database ->prepare ("SELECT name AS name , etc AS etc FROM mm_products WHERE brand = ?") ->execute ($thisUserPreferences->brands_liked);

Daher —wahrscheinlich aus mangelnder SQL-Kenntnis heraus— hier nun eben diese, meine Frage.

Dabei auch die spezielle Frage, wie hier in diesem Zusammenhang das BLOB-Feld [brands_liked] richtig zu handhaben ist?

PHP-Code:

WHERE brand = ?

...wird da so allein ja wohl kaum funktionieren, oder?

Zitat:

Zitat von Tim G

So richtig blicke ich auch noch nicht durch. Du willst, dass sobald ein Mitglied angemeldet ist, es nur noch seine Favoriten Marken sieht. Richtig?
Sobald Du einen Filter laufen hast für das beschriebene Szenario, sollten die weiteren Filter eh eingegrenz sein.

Vielleicht hast Du mich falsch verstanden. Mein Ziel ist folgendes:

MM-FE-Produkt-Filter mit folgenden Komponenten:

• Veröffentlichungsstatus (selektiert nur die aktivierten Produkte; funktioniert bereits)

• SQL-Filter für "Bevorzugte Marken" (nur Produkte deren Marke mit den separat / fest gespeicherten Präferenzen des Mitglieds aus tl_member.brands_liked übereinstimmen; fehlt mir hier noch!)

• Einzelauswahl für "Marken" (damit sich das Mitglied —im Moment der Session— seine Liste mit Produkten seiner bevorzugten Marken weiter auf eine konkrete Marke runter-filtern kann; funktioniert bereits, aber bis dato eben nur mit allen Marken als Grundlage...)

• Einzelauswahl für "XYZ" (damit sich das Mitglied —im Moment der Session— seine Liste mit Produkten seiner bevorzugten Marken auch nach Attribut XYZ runter-filtern kann; funktioniert bereits, aber bis dato eben nur mit allen Marken als Grundlage...)

Ist doch richtig verstanden.
Die SQL Abfrage für den Filter sollte nicht das Problem sein mit Inserttags. Du wirst wohl verschachtelt abfragen müssen ala Select brands_like from tl_member where id={{user::id}}
Das ganze nur auf gesicherten Seiten sonst gibts sql Fehler, wenn keiner angemeldet ist.
Sobald der Filter greift kannst du in den einstellungen ja sagen, dass nur noch weitere Treffer angezeigt werden. Damit sollte alles passen.

Sent from my iphone using Tapatalk

Hallo Tim,

also gut, danke Dir für das Finden meiner eigentlichen Frage:

Wie muss diese verschachtelte SQL-Abfrage in der Textarea der "eigenes SQL"-Komponente in diesem Fall konkret aussehen?

WHERE brand = (SELECT brand_like FROM tl_member WHERE username = {{user::username}} OR id = {{user::id}})

optional hinten ob username oder id. ich steh auf id. :)

Ich werde mal einen filter - Typ ala Hook-Funktion für MM erstellen. Der Tabimporter hat diese Option und damit sind weitverzweigtere Funktionen bequemer möglich ohne einen komplett eigenen Filter-Typ für jede Situation zu erstellen.

Wenn es so "einfach" wäre...

Wie ich gelernt habe, so muss in der SQL-Textarea immer

SELECT id FROM {{table}}

mit dabei sein. Also lautet Dein Tipp an dieser Stelle:

SELECT id FROM mm_products WHERE brand = (SELECT brands_liked FROM tl_member WHERE id = {{user::id}})

und wirft mir so zumindest auch keinen Error mehr, aber die Liste bleibt für das angemeldete Mitglied leer, obwohl es in brands_liked passende Marken-IDs hinterlegt hat...

tl_member.brands_liked ist ja ein Mehrfachauswahl-Feld vom Typ BLOB, welches (genauso wie mm_products.brand) die Marken-ID(s) aus einem dritten MetaModel mm_brands referenziert. Das (mehrfache IDs in einem Feld..) wird der Grund sein, weshalb Dein Tipp so nicht funktioniert, oder!?

Muss da nicht noch irgendwo ein LIKE-Keyword, oder ähnliches, rein?

Hab da schon alles mögliche probiert, doch leider ohne Erfolg...

Mhh... als BLOB ist natürlich ungünstig. Kriegst Du da einen anderen Feldtyp rein, damit einfach kommagelistete Zahlen gespeichert werden. Dann würde man zumindest über ein FIND_IN_SET rankommen.
Das BLOB bekommst du denke ich nur in einem eigenen Filtertyp bzw. Hook (siehe meine Idee für einen Filtertyp) aufgebröselt.
Vielleicht fällt aber jemandem noch ein eleganterer Weg ein.

Aha.. Hab ich's doch geahnt: mit BLOB stehe ich eh auf Kriegsfuß; soll heissen ich habe die Dinger noch nie richtig verstanden..!?

Dann probiere ich den Feldtyp mal zu ändern, und probiere es dann noch einmal...

Danke für Deinen Hinweis!

Sind halt wie Arrays zubehandeln bzw. json Objekte. Ich komm damit auch immer nur in einer reinen Programmierumgebung klar. Sicher bietet SQL einige Funktionen um damit innerhalb von Mysql zu arbeiten, aber da bin ich auch überfragt.

Wenn ich den Feldtyp von BOLB auf VARCHAR(64) setze, erhalte ich für das brands_liked-Feld nun wiederum (dennoch) serialisierte Daten, anstatt schlicht und einfach komma-separierte ID-Werte...

Ne Idee, wie ich das Mehrfachauswahl-Feld konfigurieren muss, um solche komma-separierten Werte zu erhalten?

Im Moment sieht die Konfiguration bei mir wie folgt aus:

PHP-Code:

'brands_liked' => array ( 'label' => &$GLOBALS['TL_LANG']['tl_member']['brands_liked'], 'exclude' => true, 'filter' => true, 'inputType' => 'checkbox', 'foreignKey' => 'mm_brand.name', 'eval' => array('multiple'=>true, 'feEditable'=>true, 'feGroup'=>'personal') ),

Kannst im save_callback die Werte umschreiben. Contao behandelt Selects hat als BLOBs (ist ja auch eigentlich richtig so. :) Aber ungünstig für dich :) )

Klingt gut, aber ich hab mit save_callback und Konsorten bisher noch keine Erfahrung.

Was ist da (genau) zu tun? Muss ich dafür eine eigene Klasse anlegen? Oder wie funktioniert das? Ist das irgendwo dokumentiert?

Zitat:

Zitat von Hendriks

Klingt gut, aber ich hab mit save_callback und Konsorten bisher noch keine Erfahrung.

Was ist da (genau) zu tun? Muss ich dafür eine eigene Klasse anlegen? Oder wie funktioniert das? Ist das irgendwo dokumentiert?

'brands_liked' => array
(
'label' => &$GLOBALS['TL_LANG']['tl_member']['brands_liked'],
'exclude' => true,
'filter' => true,
'inputType' => 'checkbox',
'foreignKey' => 'mm_brand.name',
'eval' => array('multiple'=>true, 'feEditable'=>true, 'feGroup'=>'personal'),
'save_callback' => array(array('tl_member_myExtensionName', 'mySaveCallback')),
),

Ja, eine kleine eigene Klasse. Wird gern in die gleiche Datei (z.B. in deine /dca/tl_member.php) geschrieben:

PHP-Code:

class tl_member_myExtensionName extends backend { public function mySaveCallback($varValue, DataContainer $dc) { return $varValue; } }

Steht aber auch gut erklärt in der Contao Doku.

Vielen Dank für Deine Infos und die Anregungen!

Werde mir das dahingehend nochmals genauer in der Doku zur Gemüte führen...

Überlege mir aber gerade (auch) ob BLOBs überhaupt angebracht sind — hinsichtlich einer guten Datenbank-Architektur. Vielleicht ist es besser für solcherlei Zuordnungen ("präferierte Marken", etc.) jeweils eine eigene Tabelle anzulegen!?

Also eine eigene kleine Referenz-Tabelle mit zwei Spalten:

Code:

Mitglied (ID) | Marke (ID) __________________________ 85 | 5 __________________________ 85 | 17 __________________________ 85 | 19 __________________________ 86 | 3 __________________________ 86 | 25 __________________________ |

Was ja dann auf jeden Fall den Vorteil hätte, dass man die Sache mit regulären SQL-Statements (u.a. JOINS mit den Haupttabellen, etc.) managen könnte — ohne irgendwelche "künstliche" Umrechnungen, Callbacks o.ä.

Oder wäre das u.a. aus Performance-Sicht Quatsch? Wäre in so einem Fall doch eher ein BOLB-Feld bzw. Feld mit komma-getrennten Werten angebracht / effizienter?

Was sind Deine / Eure Erfahrungen damit?

Was wäre hier Best Practice DB-Design?

Zitat:

Zitat von Tim G

Steht aber auch gut erklärt in der Contao Doku.

Würde es jetzt doch mit dem save_callback gerne probieren...

Ich kann aber keine (ausführlichere) Erklärung dazu finden. Wo meinst Du steht da was zu?

Oder wärst Du / jemand vielleicht sogar so nett, und würde/st mir die Klasse im Detail formulieren, wie die hier genau aussehen müsste...? Bzw. wie genau man der Sache mit den serialisierten BLOB-Werten vielleicht auch ausschließlich mit SQL-Mitteln Herr werden könnte...?

Würde mich für diesen Dienst dann auch gerne erkenntlich zeigen!! : o )