Tagebuch einer Extension-Entwicklung - Contao Wiki

Schritt 2: Extension-Creator
Also, los geht es mit dem Skelett für die geplante Extension. Ich verwende den Extension-Creator aus dem
Extension-Repository.
● Titel: Es geht um Turnierpaar-"Verwaltung", und um Namenskonflikte zu vermeiden möchte ich gerne
einen spezifischen Präfix nutzen: gw angelehnt an den Vereinsnamen "Grün-Weiß". Also: Titel =
gw_turnierpaare. An dieser Stelle bin ich mir noch nicht so sicher, wo dieser "Titel" überall erscheinen
wird, und ob es deshalb ein beliebiger Text sein soll, oder eher ein "identifier", also z.b. ohne
Leerzeichen u.ä. Sicherheitshalber gehe ich den Identifier-Weg. Besser hässlich als nicht-funktionierend.
● Ordnername: Ebenfalls gw_turnierpaare.
● Autor, Copyright und Lizenz: Selbsterklärend
● Paket: Ein Paketname ist gefragt. Der Hilfetext unter dem Eingabefeld schlägt hilfreich "z.B.
meinEigenesModul" vor. Ist das Modul jetzt das Paket? Was ist ein Paket? Sowas wie ein Namensraum?
Da ich noch nicht weiß, ob ich für die Vereinsseite noch andere Extensions pogrammieren werde,
nehme ich die Vereinsabkürzung als "Paketname", also "GW". Weitere vereinsspezifische Extensions
würde ich dann in dasselbe Paket stecken.
● Ein Backend-Modul hinzufügen: Ja klar, schließlich sollen Daten im Backend bearbeitet werden. Also
dort ein Häkchen.
● Backend-Klassen: Wenig hilfreicher Erklärungstext: "Hier können Sie eine kommagetrennte Liste der zu
erstellenden Backend-Klassen eingeben." - Was sind Backend-Klassen? Wofür brauche ich die?
Eigentlich müsste doch alles, was ich im Backend vorhabe, durch Einträge im DCA-File realisierbar sein,
schließlich geht es nur um Pflege von zwei abhängigen Datenbanktabellen. Also mal mutig leer
gelassen, falls das falsch ist kann man es später noch hinzufügen.
● Backend-Tabellen: Das sind wohl meine Datentabellen, ich will eine für Turnierpaare, eine für
Meldungen, also: "tl_gw_turnierpaare,tl_gw_meldungen".
● Backend-Templates: Auch hier wieder wenig erhellender Hilfetext. Auch das TL-Buch beschränkt sich da
leider fast auf das Abschreiben der Hilfetexte unter den Eingabefeldern. Ich kenne Templates nur für
das Frontend, also beschließe ich mutig, dass ich das wohl nicht brauche. Sollte sich das später als
Irrtum herausstellen, wird es sich hoffentlich noch korrigieren lassen.
● Ein Frontend-Modul hinzufügen: Aber klar, die Daten sollen schließlich im Frontend visualisiert werden.
Also Haken dran.
● Frontend-Klassen: So weit wie ich es bisher verstanden habe, braucht jedes Modul eine eigene Klasse.
Nach meiner bisherigen Planung brauche ich ein Modul "Turnierpaarliste" inklusive Detail-Ansicht der
einzelnen Paar-Einträge. Die Unterscheidung aktiv/nicht aktiv würde ich gerne über einen Parameter im
Modul lösen, so dass dasselbe Modul die Liste der aktiven und der ehemaligen Paare anzeigen kann.
Außerdem benötige ich ein Modul "Meldeliste" mit der chronologisch sortierten Übersicht der
Meldungen. Also: "gwTurnierpaarliste,gwMeldeliste" als Klassennnamen.
● Frontend-Tabellen: Ratlosigkeit. Was unterscheidet Frontend-Tabellen von Backend-Tabellen? Da ich
meine Tabellen schon in den Backend-Tabellen abgehandelt habe, lasse ich das Feld leer.
● Frontend-Templates: Natürlich! "gw_turnierpaarliste,gw_turnierpaarliste_detail,gw _meldeliste" fallen
mir sofort ein, vielleicht genügt das schon. Falls nicht, kann ich später noch welche hinzufügen.
● Sprachpakete erstellen: Natürlich. Auch wenn es wahrscheinlich niemand in Englisch benutzen wird, tut
es mir aber auch nicht weh, also Sprachen = "en,de".
Tagebuch einer Extension-Entwicklung bis 104.odt Seite 10 von 121