Formular triggert Auflistung ?

[stefanwin]

Hallo, ich beschäftige mich erst seit kurzer Zeit mit Web-Seiten und mit Contao.
Meine Anforderung ist, dass ein Frontend User (Seitenbesucher) mit Hilfe eines Formulars Suchkriterien auf der Seite definiert und er dann darunter einer Auflistung jener Mitglieder erhält, die diesen Kriterien entsprechen.
Nun dachte ich mir, ich erstelle mit dem Formulargenerator ein entsprechendes Formular und binde es als 1. Inhaltselement auf der Seite ein.
Darunter binde ich Modul vom Typ "Auflistung" ein, dass ich auch bereits erstellt habe.
Aber wie triggert jetzt der Absendebutton des Formulars die Auflistung bzw. wie übergebe ich dem Modul Auflistung die eingegeben Suchparameter für die SQL Query ? Oder ist das ein völlig falscher Ansatz ?

[soweit_ok]

Also ich finde Deinen Ansatz jedenfalls nicht falsch. Die Standardsuche des Auflistungsmoduls ist ja auch nur ein Formular.

Ist schon ne Weile her, dass ich mir mal den Quellcode des EFG und des Auflistungsmoduls anschaute, habs nicht mehr im Kopf. Aber jedenfalls speichert EFG die Formulare in der Datenbank. Wahrscheinlich würde ich deshalb keine Parameterübergabe machen, sondern die zum Zusammenbau des SQL-Statements nötigen Infos zur erweiterten Suche im Auflistungsmodul direkt aus der DB holen. Dafür das Auflistungsmodul entsprechend erweitern, das für die jeweilige Auflistung nötige EFG-Formular im BE wählen zu können. Desweiteren wäre im Auflistungsmodul eine Funktion nötig, die daraus die Query generiert. Und letztlich müsste noch die Befüllung des Template-Arrays angepasst werden.

Ich glaube, am idealsten wäre eine universelle Lösung, die in jeglichen Auflistungen flexibel funktioniert. Denn das Problem mit der zu spartanischen Standardsuche hat man ja nicht nur bei der Mitgliederliste.

Mit zwei aufeinanderfolgenden Inhaltselementen denkst Du vermutlich an eine aut. Zuordnung. Würdest Du jedoch nicht auch ein Merkmal einbauen, woran das modifizierte Auflistungsmodul die Zugehörigkeit erkennt, wäre es wohl suboptimal. Denn es kann schließlich auch vorkommen, dass ein Formular und darunter eine Auflistung ohne eine solche Verknüpfung auf einer Seite platziert werden sollen. Wenn Du es stattdessen Du es für die Auflistung anhand eines zusätzlichen Auswahlfeld aus der DB holst, bräuchtest Du das garnicht als Inhaltselement.

[stefanwin]

Nun ja, es war wesentlich einfacher als ich dachte.
Mein Formular mit den Suchkriterien führt im Hook einfach ein DB-Update auf die Definitionen des betreffenden Auflistungsmoduls durch (z.B: tl_module->list_where) .
Beim Absenden des Formularbuttons wird auch das darunter liegende Auflistungsmodul "erfrischt" und zeigt alles korrekt an.
Ob ich damit schon alles was ich brauche umsetzen kann, wird sich noch erweisen :-)

[soweit_ok]

Interessant. Dann vermutlich auch einfacher als ich dachte. Wenn es so leicht ist, individuelle Formulare als Filterkriterien einzubinden, braucht man ja garkeine universelle Lösung, wie ich es mir vorstellte. Denn mir fallen für meine Webseiten momentan bloß 3 Auflistungen ein, wo es derzeit sehr nützlich wäre.

Welchen Hook hast Du denn verwendet? Weißt Du evtl., ob´s den auch schon in Contao 2.x gab?
Magst Du vielleicht den Code Deiner Lösung posten? Ich würde mich über die Ideenvorlage freuen - andere User vielleicht ebenfalls.

[stefanwin]

Bei der Implementierung ist mir dann noch klar geworden, dass die Lösung mit der Modifikation der 'tl_module' zwar funktioniert, aber natürlich nicht Multiuser-fähig ist :-).
Also habe ich dann doch eine Session-Variable erfunden, die vom Formular im processFormData-Hook gesetzt wird.
Zusätzlich gibt es im Suchformular ein verstecktes Feld, wo ich die ID der betreffenden Auflistung definieren kann. Leider musste ich dann auch das Listingmodul direkt modifizieren. Im destructor() lasse ich zusätzlich die Session-Variablen wieder zurücksetzen, damit die nächste Suche wieder den richtigen Startpunkt hat.

class myFormCheck extends Frontend
{ 
    /** 
     * eigene Pruefung f. Abschicken d. Formulars per Hook 'processFormData' 
     */ 

	public function myProcessFormData($arrPost, $arrForm, $arrFiles)
	{
    		// Suche
		if ($arrForm['formID'] == 1710)
		{
			// Module Parameter anpassen
			self::ModMyMod($arrPost, $arrForm, $arrFiles);

		}
		// Module Parameter anpassen
	        public function ModMyMod($arrPost, $arrForm, $arrFiles)
	        {
		     // SQL Query Parameter f. Listing
                     $_SESSION['LISTING']['list_where'] = "(user_plz" . "=" . $arrPost['user_postcode'] . ")";
                     // ID des betreffenden Moduls 'Auflistung'
                     $_SESSION['LISTING']['list_id'] = $arrPost['listing_id'];
                 }

und noch im "ModuleListing.php":

function __destruct()
{
     if ($_SESSION['LISTING']['list_id'] == $this->id) 
     {
         $_SESSION['LISTING']['list_where'] = '';
     }
}

in der generate() Methode:

// Listing aus einem Formular triggern (Suchkriterien)
if ($_SESSION['LISTING']['list_where'] != '')
{
     if ($_SESSION['LISTING']['list_id'] == $this->id) 
    {
         $this->list_where = $_SESSION['LISTING']['list_where'];
    }
}

Leider ist das Ganze zwar recht einfach gelöst, aber eben nicht "Updatesicher", doch da finde ich vielleicht noch eine Möglichkeit.

[soweit_ok]

Danke für den Code. Schonmal gut zu wissen, dass die Verwendung eigener Suchformulare nebst zugehöriger eigener SQL-Query so tatsächlich klappt.

Wenn ich es richtig blicke, war das erstmal ein Funktionstest bzw. könntest Du auf diese Weise nun auch mehrere Felder in das Array packen und die SQL-WHERE-Bedingung dazu. Denn für die PLZ wäre es ja nicht nötig, weil nach den mittels Checkbox gewählten Feldern filtert ja auch die Standardsuche. Sofern eindeutiges Suchkriterien wie eine bestimmte PLZ. Suche nach Bereichen wie z. B. "PLZ von bis" oder "Alter von bis" geht anscheinend nicht, weil die Standardsuche nur ein Eingabefeld anbietet. Außerdem wohl auch keine Regular Expressions verarbeitet, zumindest nicht in der bei mir installierten Version. Aber selbst wenn, könnte man den Usern doch keine Eingabe von Suchmustern zumuten.

Am sympathischten fände ich, ließen sich im BE-Standardlistingformular die "sichtbarern" Einzelfelder als Feldgruppen zusammenfassen mit SQL-Bedingung für jede dieser Gruppen. Und diese Feldgruppen wiederum untereinander erstmal nur mit AND verknüpfen. Optional zusätzliche Klammerung und ODER-Verknüpfungen wären für den häufigsten Anwendungszweck glaub ich nicht unbedingt nötig. Doch für solche generelle Flexibilität müsste man eben das ganze Modulpaket aufwändig umfrickeln. Aus diesem Aspekt heraus finde ich höchst interessant, was Du da ausgetüftelt hast. Weil man auf einer Webseite normalerweise höchstens eine Handvoll Auflistungen hat, die solche individuellen Suchmasken bräuchten, ist der Aufwand so natürlich viel kleiner. Okay, dass es (noch) nicht updatesicher ist, finde ich nicht sooo schlimm.

Bei Updates brauch ich sowieso meist mindestens 2 Wochen, meine diversen nicht updatesicheren Änderungen sowie für mich unverzichtare inkompatible Erweiterungen wieder anzupassen.

Was ich an Deiner aktuellen Lösung noch etwas suboptimal finde, ist eher die hart kodierte Formular-ID aus dem versteckten Feld bzw. dass für jedes neue Listing mit individuellem Suchformular die Fallunterscheidung mit dem daran hängenden Gebamsel im Quellcode erweitert werden müsste. Ich werd mir diese Baustelle auf jeden Fall demnächst auch mal reinziehen, weiß bloß noch nicht, wann ich Zeit dafür finde.

Du bist ja noch neu in der Community und anhand der bisher wenigen ersten Postings kann ich nicht einschätzen, wie häufig Du das Forum besuchst bzw. nach neuen Postings in älteren Deiner Threads schaust. Darf ich Dir eine PM senden, wenn ich mich mit diesem Thema ebenfalls eingehender befasse? Einerseits interessiert mich dann natürlich möglichst zeitnah Deine dann letzte Änderungsversion und vielleicht fällt mir ebenfalls noch die eine oder andere Optimierung ein. Oder, falls Du PM manchmal vllt. erst nach längerer Zeit findest, magst Du mir eventuell eine Emailadresse geben, unter der Du erreichbar bist? Keine Sorge, ich belästige garantiert niemanden. ;-)