Filter Workaround

Hallo, ich bin neu in der oxCommunity und stehe beim einrichten meines ersten Test-Shops vor einem Dilemma: Ich möchte einen Farbfilter erstellen, sodass ein Artikel unter mehreren Farben gelistet werden kann. Es gibt auch schon ähnliche Threads, trotzdem ist das Problem - so einfach es sein mag - auf seine weise “einzigartig”. :slight_smile:

Zunächst möchte ich ein Workaround nutzen: es gibt mehrere Attribute color_black, color_white, usw. Wenn der Artikel das Attribut hat, wird er unter der Farbe gelistet. Somit fällt also der klassische Dropdown Filter erstmal weg, da jeder Artikel nur eine Farbe hätte; aus optischen gründen möchte ich sowieso kein form benutzen, also übergebe ich zunächst aus dem list.tpl einen parameter mit &color=…

Im weiteren ist mir das ganze Filter-System vom Oxid Shop allerdings ein Rätsel. Allein das Aktivieren des SessionFilters erfordert ja normalerweise eine dropdown auswahl in der list.tpl über das absenden einer kryptischen ID mit dem filter-formular. Solange das nicht passiert ist, bleibt natürlich auch mein aSessionfilter leer und der table select läuft ohne _getFilterSQL.

[B]Kurz gesagt[/B]: ich habe ohne das filter-formular ein Attribut, nach dessen Vorhanden-Sein ich filtern möchte, also muss ich irgendwie diesen Filter selbst in die Session bringen und den Filter aktivieren. :confused:

Danke fürs Lesen

Das ist nicht schwer: Filterwerte senden, Filterwerte abfragen (GET / POST // AJAX), Query erstellen und Artikel ausgeben lassen. Wie man die Artikelliste überlädt, steht hier im Forum.

Aber was hat ein Form-Tag mit der Optik zu tun?

Mit Optik meine ich, dass ich Grafik-Buttons nutzen möchte, also es kommt nicht die klassische Variante mit form/select/option in frage. Es macht ja keinen Sinn wenn ich meine Attribute (color_black,color_white,etc.) der Kategorie zuweisen, diese haben ja keine values, die ich nutzen möchte.

Mir fehlt also erstmal der Einstieg, wo die Filter Werte vom Formular in die Session kommen und wo der Filter aktiviert wird, da ich meinen Parameter dort gesondert behandeln muss.

Na, das wird aber ein großer Workarround.

Die Filterwerte (Attribute) werden den Artikeln zugeordnet und entsprechend im Filter als auszuwählende Werte verankert. Wird ein Filter betätigt, werden nur Artikel mit dem gewählten Attribut eingeblendet. Dies kann per AJAX ohne reload erfolgen oder halt eben mit. Ohne FormTag als Link mit JS wäre es auch machbar:

onclick="document.name.submit();

Die Filterwerte werden mit Benutzung in eine Session geschrieben. Wie das funktioniert, steht hier im Forum.

Zunächst einmal stellt sich aber die Frage, wie komfortabel der Filter sein soll. Willst Du den Filter mit Werten über den Admin erstellen oder im Quelltext?

Zunächst mal will ich ohne Admin Modul arbeiten, sodass ich ein paar Farben “festlege”. Wenn das funktinoiert, kann ich einen Schritt weiter denken.

Besagten Link im Forum hab ich schon studiert
http://www.oxid-esales.com/forum/showthread.php?t=4702

Hier wird aber am Ende auch über ein Formular übergeben. Damit wird der Filter ganz regulär aktiviert und das Attribut in $aSessionFilter geschrieben. Wenn dann alist.php den Parameter übernimmt mit oxSession::getVar(‘session_attrfilter’) ist der entscheidende Punkt schon passiert: Der Filter ist schon aktiv und das Formular ist schon in die Session übergeben.

Und was ist jetzt die Frage? Wie die Values in die Session kommen?
z.B. so:

$_SESSION["wert"] = $_GET / $_POST["wert"] 

Den Parameter übernehme ich mit oxConfig::getParameter, das ist kein Problem.

Ich suche eher die Funktion im Oxid Source Code, die das Formular [I]_filterlist[/I] mit seinen einzelnen Werten abgreift und in die Variable [I]session_attrfilter [/I]schreibt.

Update ++ bin jetzt einen Schritt weiter:

Ich erweitere $aSessionFilter in der Funktion alist/executefilter()

sowie $aAttributes über oxcategory/getAttributes()

Filtern mag der Shop bis jetzt aber noch nicht :-\

Update + Problem gelöst:

Ich übergebe color=… & fnc=executefilter als Parameter beim click auf einen Hyperlink. Das ist nicht sehr elegant, aber auf diese Weise brauche ich weder JavaScript, noch <form>.

executefilter() hat die ganze zeit funktioniert und den sessionFilter korrekt angepasst. Das Problem lag in der Funktion [B]alist/_loadArticles[/B]. Dort wird der Parameter ebenso mit getVar ausgewertet. Meine Anpassung in executefilter() wurde also vom Frontend einfach nicht aufgerufen.