Relation von tl_form zu tl_formdata ist der Formularname (String)?

[zonky]

... ich habe mir gerade mal die Tabellen angesehen... stehe ich auf dem Schlauch oder ist Relation von tl_form zu tl_formdata ist der Formularname? Spalte "form" in "tl_formdata"

zumindest "verschwinden" die von EFG gespeicherten Formulareingaben, wenn ich im Formulargenerator den Titel ändere...

ähhh... warum keine ID bzw. PID wie "üblich"??

[cliffparnitzky]

Moin,

jup, das ist richtig.

Warum? Hmmm, gute Frage, kann ggf. nur der Entwickler sagen

Musst die Entries (tl_formdata) dann per SQL auf DB Ebene updaten.

Gruß, Cliff

[zonky]

Warum? Hmmm, gute Frage, kann ggf. nur der Entwickler sagen

... gehe mit der Annahme schwanger, der "Entwickler" guckt hier ab und an vorbei... :-)

oder jemand der anderen EFG-Novizen könnte die Frage (er)klären ;-)

[tom]

Hallo zonky,

das hat v.a. mit den ursprünglichen Anforderungen an die Erweiterung zu tun.

Bei Verwendung der üblichen Relation per PID würden alle Formulardaten (ohne Versionierung o.ä.) gelöscht, sobald das "zugehörige" Formular im Formulargenerator gelöscht wird.
Genau dies durfte aber nicht geschehen.

Status quo "verschwinden" sie und sind unter "Feedback" zu finden.

Schöne Grüße
Tom

[zonky]

das automatische Löschen würde m.E. nur passieren, wenn die Relation fest in der DB angegeben ist z.B. per InnoDB

ich kenne aber kaum ein Projekt, wo das wirklich genutzt wird - hier bei Contao habe ich das auch noch nicht bemerkt...

Aus der Hüfte geschossen würde ich sagen, dass es kein Problem wäre eine PID-Spalte (int) einzufügen mit dem Verweis auf die tl_form un somit wäre es egal "wie das Kind heißt"

Sofern man aus der EFG-Tabelle zurück auf die Form-Tabelle schließen will (eigene Programmierung) wäre mir ein fester Int-Wert lieber als ein "labriger" String-Vergleich.

[tom]

das automatische Löschen würde m.E. nur passieren, wenn die Relation fest in der DB angegeben ist z.B. per InnoDB

nein, das hat mit der DB nichts zu tun. Dafür ist die DC_Table::reviseTable() verantwortlich, die bei "üblichen" Relationen (per PID und ptable/ctable im DCA) alle "verwaisten" Datensätze löscht.

[zonky]

und da gibt es keine Option "lass mich in Ruhe!"?

[tom]

Hallo zonky,

jaein. Temporär die "Relation" im DCA "kicken".
Da ich aber die "übliche Relation" gar nicht möchte, halte ich das für den falschen Weg.

An welcher Stelle benötigst Du denn den "Rückschluß" auf Das Formular? Im Backend?
Ich kann gerne ein zusätzliches Feld 'form_id' / 'fid' in der tl_formdata ergänzen(?)

Schöne Grüße
Tom

[zonky]

Hintergrund:

* ich habe Vortragsvorschläge, die per Formular eingehen und per EFG-Listenausgabe wieder ausgegeben werden
* in dem Listing soll für jedes Item ein Rating-Modul rein, damit jeder seinen "Best-of" wählen kann - z.Z. bastle ich an RateIt
* dafür muss ich dem RateIt-Element ein paar "IDs" mit auf den Weg geben - dachte an die Item-Id + die Formular-ID => damit dürfte ich "Contao-Weit" unique sein...

=> damit ist die "Suche" nach der Formular-ID begründet...

[andreasisaak]

Wieso befüllst du mit dem Formular nicht direkt ein MetaModel und lässt die Einträge mit dem rating Attribut bewerten?

[zonky]

... wir haben hier in Berlin mal einen Workshop zu MM gemacht (V 1.x) aber würde mir das nicht zutrauen bzw. hätte erstmal keinen Plan zur Umsetzung...

gibts irgendwo ein Beispiel/Snippet was (i.E.) passt?

[Tim G]

Die id muss nicht die formular-id sein, wenn die Daten in einer autarken Tabelle abegelegt werden. Andreas Weg geht mit dem processEfgFormdata Hook sehr gut.
Der teilweise hardkodierte Aufbau der formdata kann sehr unangenehm werden. Für das schnelle Speichern und anzeigen ok. Fürs weiterverarbeiten, nein. Ich glaube das war auch nicht die Intention. Bei jedem neuen Formularfeld muss das ganze Formular neugespeichert werden, sonst fehlt das Feld.

[zonky]

Die id muss nicht die formular-id sein, ...

ich kann natürlich auch selbst eine "generieren" oder irgendwas anderes nehmen - m.E. würde sich das anbieten für die "Beantwortung" der zwei Fragen

* welches EFG-Speicher-Item bin ich?
* zu welchem Formular gehöre ich?

damit ist/wäre die Zuordnung in Rateit eindeutig - und das egal ob ich das Item an mehreren Stellen bewerte wie z.B. die Auflistung, die Detailseite, sonstwo...

[Tim G]

ich kann natürlich auch selbst eine "generieren" oder irgendwas anderes nehmen - m.E. würde sich das anbieten für die "Beantwortung" der zwei Fragen

* welches EFG-Speicher-Item bin ich?
* zu welchem Formular gehöre ich?

damit ist/wäre die Zuordnung in Rateit eindeutig - und das egal ob ich das Item an mehreren Stellen bewerte wie z.B. die Auflistung, die Detailseite, sonstwo...

na dann mach es doch

[zonky]

na dann mach es doch

... wo wir wieder am Anfang sind... da ich nicht verstanden habe, warum man nicht von den Items auf die Formulartabelle über eine eindeutige ID kommt... wenn der Name des Formulare geändert wurde, und sei es nur ein Schreibfehler, ist die "Verbindung" zur Formulartabelle gekappt => siehe oben!

[Tim G]

Tom hat's Dir doch erklärt. Der DC_Table kümmert sich um Tabellen, die in einer Elternkindbeziehung stehen (mode 4) und würde in diesem Fall die Kinddatensätze löschen, wenn man nicht über den reviseTable Hook das blockt (siehe die GlobalContentElement Erw.). Aber das wäre auch wieder ein Hack.
Tom will das die Daten immer existieren, auch wenn das Formular gelöscht wird, damit man nachträglich auf eigentlich veraltete Formulardaten zurückgreifen kann, auch wenn das Formular gar nicht mehr existiert.

Bau dir das doch selbst mal auf. Ein kleines Mockup ist viel leichter hier. In Contao 3 gehts sogar bissel leichter, weil ctable dynamisch sein kann. Das macht viel aus.
Du kannst ja sogar den DCA der tl_form und tl_formdata Umbauen auf pid 1n Beziehung. Dann siehst Du was gemeint ist.

Relation von tl_form zu tl_formdata ist der Formularname? Spalte "form" in "tl_formdata"

Relation ist der alias bzw. die forumular_id (string), nicht der Formularname

[zonky]

o.k.!

[tom]

... wo wir wieder am Anfang sind... da ich nicht verstanden habe, warum man nicht von den Items auf die Formulartabelle über eine eindeutige ID kommt... wenn der Name des Formulare geändert wurde, und sei es nur ein Schreibfehler, ist die "Verbindung" zur Formulartabelle gekappt => siehe oben!

für die RateIt benötigst Du die ID des Formulars nicht.
Du möchtest ja kein Formular bewerten, sondern einen Eintrag/Datensatz der "Formulardaten" (Tabelle tl_formdata), der über dieses Formular erzeugt wurde.
Die RateIt benötigt (in Tabelle tl_rateit_items):
'rkey': die ID des bewerteten Datensatzes (also tl_formdata.id, steht Dir in den EFG-Auflistungstemplate bei jedem Feld zur Verfügung)
'typ': i.d.R. 'article'/'news'/... , es sollte aber funktionieren, hier z.B. 'formdata' o.ä. zu verwenden
'title': hier den gewünschten Wert Deines Formulardaten-Eintrags verwenden (dient m.E. zur Gruppierung/anzeige der RateIt-Einträge im Backend)

[andreasisaak]

... wir haben hier in Berlin mal einen Workshop zu MM gemacht (V 1.x) aber würde mir das nicht zutrauen bzw. hätte erstmal keinen Plan zur Umsetzung...

gibts irgendwo ein Beispiel/Snippet was (i.E.) passt?

Wieso Snippet? Das kannst du dir doch bequem im Backend zusammenklicken. Im Wiki findest du auch einige Anleitungen dazu Ich würd an deiner Stelle gar nicht erst Angst davor haben. Schwerer als den EFG umprogrammieren kann es nicht sein Bei MetaModels klickst du dir 90% der Zeit alles im BE zusammen.

[tom]

Hallo Andreas,

Wieso befüllst du mit dem Formular nicht direkt ein MetaModel und lässt die Einträge mit dem rating Attribut bewerten?

das MetaModel rating Attribut arbeitet aber nicht mit RateIt zusammen, oder doch?

[zonky]

das MetaModel rating Attribut arbeitet aber nicht mit RateIt zusammen, oder doch?

muss/müsste auch nicht - Hauptsache die Sterne sind da ;-)

[tom]

Ich werd's mir in der Mittagspause mal anschauen.

EFG "umprogrammieren" wirst Du sicherlich nicht müssen. Evtl. aber RateIt "beibringen" (evtl. eigenes JS), auch Einträge aus anderen Tabellen/Modulen bewerten zu können.

NACHTRAG:
Wie vermutet, akzeptiert RateIt im Frontend per Ajax nur die "Typen" page|article|ce|module|news|faq|galpic
Diese sind in zwei Dateien (public/php/rateit.php und public/js/rateit.js) "hartcodiert". Sobald ich dort z.B. 'formdata' ergänze, kann ich mit einem angepassten EFG-Auflistungs-Template (ergäzt um den für RateIt benötigten DIV) Formulardaten-Einträge bewerten.
Voraussetzung ist allerdings zusätzlich, dass in der Tabelle tl_rateit_items für jeden zu bewertenden Formulardaten-Datensatz ein Eintrag existiert. Dafür ließe sich per Hook sorgen.

Möglicherweise ist der Entwickler der RateIt bereit, eine Möglichkeit vorzusehen, auch eigene "Typen" zu verarbeiten?

Alternativ könntest Du die Formulardaten als "Typ" 'article' bewerten, was allerdings im Backend bei den RateIt-Auswertungen eher ~verwirrend~ wäre.
Da die von RateIt benötigte "ID" des zu bewertenden Eintrags lediglich 'numeric' sein muss, aber eine Länge von 32 Zeichen haben kann,
wärst Du mit einer "ID" nach Schema 987654321 . <ID-des-Formulardatensatzes> oder etwas ähnlichem sicherlich "auf der sicheren Seite" bzgl. Eindeutigkeit.

[andreasisaak]

Hallo Andreas,


das MetaModel rating Attribut arbeitet aber nicht mit RateIt zusammen, oder doch?

Nein es hat ein eigenes Bewertungssystem.

[tom]

Hast Du Dir RateIt mal angesehen?
Der Begriff "eigenes Bewertungssystem" (mooStarRater glaube ich?) ist da schon etwas hoch gegriffen?

[andreasisaak]

Wieso hochgegriffen? Das "system" bezog sich lediglich darauf das die Bewertungen in eine MetaModels spezifische Tabelle wandern und abgekoppelt vom Rest der Seite sind. Also nicht auf Artikel oder Seiten umzumünzen sind. Ich habe nirgendwo geschrieben das wir ein eigenes JS dafür geschrieben haben.

[zonky]

'rkey': die ID des bewerteten Datensatzes (also tl_formdata.id, steht Dir in den EFG-Auflistungstemplate bei jedem Feld zur Verfügung)
'typ': i.d.R. 'article'/'news'/... , es sollte aber funktionieren, hier z.B. 'formdata' o.ä. zu verwenden
'title': hier den gewünschten Wert Deines Formulardaten-Eintrags verwenden (dient m.E. zur Gruppierung/anzeige der RateIt-Einträge im Backend)

'rkey' ist nicht "Normiert" sondern die "Gruppen-ID" und die "Item-ID" zusammen per Pipe getrennt drinnen...

[zonky]

Ich werd's mir in der Mittagspause mal anschauen.

EFG "umprogrammieren" wirst Du sicherlich nicht müssen. Evtl. aber RateIt "beibringen" (evtl. eigenes JS), auch Einträge aus anderen Tabellen/Modulen bewerten zu können.

an RateIt bin ich drann...