Tagebuch einer Extension-Entwicklung - Contao Wiki

deerwood
nochmals etwas weiter gedacht:
Mitglieder-Gruppen (tl_member_group) gibt es ja schon in TL mit allem Drum und Dran / Verwaltung. Vielleicht
muss man für Mannschaften/Paare nur noch einige Felder und Logik ergänzen?
Und was sind denn Turniere/Veranstaltungen? Das sind doch "Events" (tl_calendar_events), für die es ein
Basis-Modul in TL gibt, und, soweit ich sehen kann, auch schon diverse Erweiterungen, die zusätzliche Felder
bieten.
Was fehlt also noch? Eigentlich nur die "Mitte" (Meldung) zwischen member_group und calendar_event.
Das ist halt eine zusätzliche/besondere Beziehung/Relation zwischen member_group und calendar_event, die
eine zusätzliche Logik erfordert, sobald jemand die Beziehung herstellen/bearbeiten möchte, implementiert als
Modul (und wohl mit einer zusätzlichen N:M Tabelle "Meldung/Teilnahme").
Bin ich abgeflogen, oder versteht jemand diesen Ansatz oder bin ich einfach dumm und alle machen das bereits
so?
dl1ely
vielen Dank für deinen Input. Habe ihn gestern Abend noch gelesen, aber keine Zeit/Ruhe zum Antworten
gehabt. Prinzipiell hast du mit deiner Idee sicherlich recht, auch wenn ich aufgrund von (Noch-)Unkenntnis der
schon implementierten Tabellenstruktur nicht sagen kann, ob da irgendwo noch ein Haken ist. Für ein
abstraktes "Lehrbuchbeispiel" einer Extension wäre das wohl genau der richtige Weg.
Folgende Gründe (Die alle nicht "zwingend" sind, aber die Summe macht es) machen es aber für mich
unattraktiv:
● Eine Normalisierung in Meldung und Turnier ist in 90% der Fälle Overkill. Häufig gibt es zu einem
Turnier genau eine Meldung. Häufig wird es sich also um eine 1:1-Beziehung handeln.
● Handling der "Personen" als Front-Member: Werde ich mir nochmal anschauen, aber ein großes Erbe in
meinem konkreten Fall ist leider die Notwendigkeit, schon bestehende Daten zu migrieren,
insbesondere die Liste der Turnierpaare, die bis in die 90er Jahre zurückreicht. Man kann sich
vorstellen, dass da bei aktuell 45 Turnierpaaren (=90 Personen AKTIV) über die Jahre geschätzt 300-
400 beteiligte Personen angesammelt haben, die ich alle in die tl_member-Tabelle migrieren müsste,
obwohl davon eben nur 90 überhaupt noch potentiell einloggen.
Die "Alten" nutzen die Seite eh nicht mehr, sollen sowieso nicht mehr ihre alten Einträge editieren
dürfen, und sind (ehrlich gesagt) inzwischen teilweise verstorben. Für einen Großteil der Personen, die
(inaktive) Paare bilden, müsste ich aus dem alten "Paar"-Datensatz zwei Datensätze für die tl_member-
Tabelle erstellen, und mir dabei größtenteils die Inhalte der Datenfelder (email, passwort, whatever)
ausdenken.
Natürlich sehe ich die von dir geschilderten Vorteile der Abstraktion/Normalisierung, der Verfolgbarkeit
des Wechsels von Paarzusammenstellungen, usw...Aber ich erkaufe es mir auch mit dem oben
geschilderten Overhead.
● Im Tanzpaar übernimmt meistens einer das Eintragen der Ergebnisse (meist der Herr :-). Wenn ich die
Damen auch als Member anlegen würde, würden 45% der Member-Einträge selbst der aktiven Paare
wahrscheinlich nie genutzt werden.
● Vorschlag der Generalisierung: Sicherlich erstrebenswert, aber ich sehe die Gefahr, mich vor lauter
Generalisierung "zu verzetteln", und 90% meiner Arbeit in "what-ifs" zu stecken, die in meinem Fall gar
nicht benötigt werden.
Tagebuch einer Extension-Entwicklung bis 104.odt Seite 6 von 121