Tagebuch einer Extension-Entwicklung - Contao Wiki

dl1ely
tl_member-Tabelle an, ob ich die Personen dort nicht ablege, aber aus den o.g. psychologischen
Gründen würde ich ungerne ein Frontend-Login einführen (müssen).
● Auf PHP-Seite möchte ich natürlich so weit wie möglich (und so weit es meine bisherigen Kenntnisse
des Frameworks es zulassen) auf das TL-Framework setzen. Ist doch klar!
Auf jeden Fall vielen, vielen Dank für das Feedback so weit, genau so hatte ich mir den Thread/die Diskussion
eigentlich vorgestellt. Mit Vorschlägen von Alternativen, Anbringen von Zweifeln, usw...
Sehr gerne, danke für den Tipp. Ich werde die Posts, wo es in der Extension auch wirklich vorwärts geht
zusätzlich mit roten großen Überschriften versehen, damit man später beim Lesen des ganzen Threads die
"Nebendiskussion" leichter überspringen kann.
FloB
Zitat von dl1ely
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. […]
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.
Nun, aus was bestehen denn die bestehenden Daten? Name, Geburtsdatum ist klar, dann noch Tanzpartner
(am besten UserID – oder "Gruppen-ID", sprich zwei Partner bekommen eine neue Nummer? Damit wäre auch
der Grundstein gelegt, ganze Tanzgruppen ohne Mehraufwand anzulegen), Turnierklasse, aktive Jahre. Diese
Felder kann man ja problemlos zu tl_member hinzufügen.
Wenn du diese Daten in einem bestimmten Format hast (CSV, XML o. ä.) kannst du sie per SQL importieren.
Die Daten, die du von manchen Personen nicht hast (E-Mail etc.) musst du da nicht angeben – nur wenn man
versucht diese Einträge über das Backend / Frontend zu ändern, meckert TL. Frontendanzeige sollte problemlos
funktionieren. Somit hast du die saubere Integration von Nutzer und Paaren.
OK, ich verstehe dein Argument, dass das möglicherweise ein wenig Overkill für diese Art von Daten ist. Dann
wäre es sinnvoll für Paare eine zugehörige "Verwalter-ID" zu geben, die auf einen Member-Account verweist.
Dieser Member kann dann alle Einträge ändern, auf dessen die Paare / Personen verweisen. Ein zusätzliches
Feld für die Trainer-ID (hinter dem auch ein Member steckt) in der Paarliste ermöglicht dann dem Trainer
zusätzliche Einstellungen an der Paarung vorzunehmen (z. B. Turnier bestätigen).
dl1ely
Hehe, ihr blast das Ding schon viel zu weit auf...Trainer-ID o.ä. ist nicht notwendig, Trainer spielen in diesem
"Prozess" keine Rolle. Ich denke es wird klarer (vielleicht auch enttäuschender), wenn ich die SQL-Files für
meine Daten zeige. Es ist eigentlich recht billig, gerade für einen "TL-Profi". Aber das bin ich noch nicht ;-).
Die Daten liegen noch in einer (anderen) MySQL-Datenbank. Der technische Vorgang der Migration ist kein
Problem, aber ich werde per Skript manche Felder der bisherigen Datenbankstruktur verändern müssen, um es
Tagebuch einer Extension-Entwicklung bis 104.odt Seite 8 von 121