Druckbare Version
Hallo,
habe jetzt wohl eine neue Lieblingserweiterung für mich entdeckt.
Das Speichern der Daten ist ja kein großes Ding. Habe allerdings 2 Fragen
1. Wie kann man Beiträge mit einen "published" versehen? Also das im BE die Einträge nach Prüfung freischalten kann?
2. Wie funktioniert die Auflistung? ich habe gelesen im Forum das die Daten als json in der DB stehen?
Für eine Antwort wäre ich dankbar :o:o
in tl_lead stehen nur die Daten einzelner POST Requests pro Formular. Die zusammengefassten Daten stehen in tl_lead_data. Ersteres könntest du dir mit dem normalen listing Modul von Contao ausgeben lassen. Zweiteres mit einem eigenen Template mit eigener Datenbankabfrage.
Äh das verstehe ich nicht ganz. Wie kann ich mit dem Auflist-Modul Beiträge prüfen? Also Die möglichkeit muss es doch im BE gebenZitat:
Zitat von Spooky
Mein Kommentar war nur für den Punkt 2 gedacht :)
Ich meine das geht nicht. Im BE ist nur eine Ansicht der Daten vorgesehen, keine Verwaltung.Zitat:
Zitat von Ralf2011
Vielleicht hat ja mal jemand Lust und Muße, eine Backend-Erweiterung zum Bearbeiten der Leads-Daten zu schreiben?
Published könnte man dann über ein (verstecktes) Feld im Formular realisieren.
Ich hab neulich mal für einen Spezialfall ausprobiert das Editieren ausprobiert, bin aber nicht zu einem befriedigenden Ergebnis gekommen.
Eine allgemeine Lösung müsste die Infos über die Eingabefelder aus dem zugehörigen Formular berücksichtigen - daran bin ich dann endgültig gescheitert...
Falls jemand Interesse hat, dann würde ich gerne 'mitmachen' :)
Gruß, folkfreund
Ich habe auf Leads aufbauend eine Erweiterung, mit denen sich flexible Verarbeitungsworkflows abbilden lassen. Wird eingesetzt für Supportanfragen. Bearbeiten der Daten ist bisher nicht drin, ließe sich aber einbauen. Kann allerdings derzeit nicht versprechen, dass es der Allgemeinheit zur Verfügung gestellt wird.Zitat:
Zitat von folkfreund
Was verstehst du unter "flexible Verarbeitungsworkflows"?Zitat:
Zitat von webstar
Jedenfalls ist der Zugriff auf die eingegebenen Daten eigentlich einfach - nachdem ich verstanden hatte, dass die Eingaben zweimal gespeichert werden, einmal in tl_lead als json und einmal aufgeschlüsselt in tl_lead_data, ist auch deren Änderung übersichtlich.
Damit man generisch die Daten korrigieren, editieren kann muss man also (egal ob im Backend oder Frontend) die Eigenschaften der Formularfelder kennen (Datentyp, Validierung, Pflichtfeld etc.)
Ich hab noch nicht richtig verstanden, wie die Zusammenhänge aussehen, und v.a. wie man daraus für's Backend ein passendes Formular generieren könnte. Das geht dann ja nicht per DCA, da abhängig von der Formulardefinition. Ich hab noch keine Idee, wie man das sauber und elegant realisieren könnte...
Ideas welcome :)
Okay, dann würde ich mir einfachen "link" zusenden wo ich die freischalte. :oZitat:
Zitat von Andreas
Die Daten sind nicht als JSON, sondern serialisiert in tl_lead.post_data gespeichert.Zitat:
Zitat von folkfreund
In tl_lead steht ein Datensatz je Formular-Sendung. In tl_lead_data steht ein Datensatz je Feld und Formular-Sendung welche über die pid den einzelnen Formular-Sendungen zugeordnet sind.
Ja, danke für die Korrektur, hab mich vertan :o.
Diese Doppelspeicherung hatte ich zunächst als ungeschickt empfunden. Zusammen mit einer Editiermöglichkeit der Daten in tl_lead_data wäre dadurch aber gegeben, dass man auch später noch immer auf die ursprünglich eingegebenen Daten zugreifen könnte. Kann auch Vorteile haben.
@Andreas: weißt du welchen Vorteil es bringt die Daten in dieser Form (also 2x) abzuspeichern? Mir ist die Datenbankstruktur nicht ganz schlüssig - warum einen Datensatz je Feld anlegen?Zitat:
Zitat von Andreas
Das weiß ich auch nicht. Da müsste man den Entwickler fragen.
In tl_lead stehen dort nur die POST Variablen der jeweiligen Requests drin. Die tatsächlichen Daten werden aber in tl_lead_data gespeichert und entsprechend verknüpft.
Danke Spooky,
aber warum wird bei tl_lead_data pro Datensatz ein neues Feld angelegt und nicht der gesamte Datensatz in einen Eintrag? Mich interessiert ob es dadurch Vorteile gibt bzw. ob das "state of the art" ist. Die Datenbank wird dadurch ja ziemlich aufgeblasen oder nicht? Hab das damals in der Schule noch anders gelernt ;)
Spätestens wenn man das nachträgliche Editieren der Eingaben programmieren will, dann wird man sich über die getrennte Speicherung der Daten freuen :)
In wie fern in einen Eintrag? Die Anzahl der Felder ist ja unterschiedlich.Zitat:
Zitat von janosch
Da hast du recht - Denkfehler meinerseits. Würde bei einem Formular funktionieren, bei weiteren natürlich nicht.
Moin, die folgende Frage betrifft Contao 3.35, aber ich packe es mal hier rein:
Welche Datei listet im BE die einzelnen Datensätze bei Leads?
Ich speichere Formulardaten aus dem FE in der DB. Bei dem Listing der einzelnen Datensätze im BE möchte ich eine Veränderung der gelisteten Daten sowie der Inline-CSS vornehmen.
Im Blick hatte ich die be_show_leads.html5 aber die ist es nicht. Zumindest nicht bei mir ;)
Wenn ich die HTML-Elemente vom Backend untersuche, sehe ich dort ein Inline-CSS: <span style="color:#b3b3b3; padding-left:3px;">[' . $strValue . ']</span>'
Dieser kommt in 2 Dateien vor: Leads.php im library Ordner oder die be_show_leads.html5 im templates ordner.
Egal welche Datei ich bzgl. der Farbe ändere, es ändert sich nichts. Cache ist auch gelöscht.