Der Flaschenhals der Flexibilität von TYPOlight

[webstar]

Hallo Community,

ich bin gerade dabei meine erste ernsthafte Erweiterung für Typolight zu entwickeln und stoße dabei auf eine für meine Sicht sehr empfindliche Engstelle bei dem TYPOlight Framework. Um eines zuvor klarzustellen, ich bin seit Jahren begeisterter TL-Nutzer und bin an sich begeistert von der leichten Erweiterbarkeit des Systems. Doch bin ich auf eine (wohl bekannte) Grenze gestoßen.

Was will ich machen? An sich eine Kleinigkeit. Ich will bei den Kommentaren ein Avatar ausgeben, welches anhand der E-Mailadresse von gravatar.com abgerufen wird. Normalerweise würde da ja eine kleine Templateanpassung ausreichen, doch wollte ich die Anpassung der Größe, des Ratings und des Defaultavatars über die Einstellungen des Newsarchives anpassbar machen. Deshalb habe ich das Newsarchiv um die entsprechenden Felder erweitert, ein entsprechendes Template erstellt und musste registrieren, dass es nicht funktionert.

Beim Herumstöbern im Quelltext des Comments-Moduls bin ich auch auf die Ursache gestoßen. Und zwar wird dem Template ja nur bekannte Variablen übergeben, welche im Gegensatz zu den Feldern der Tabelle, die ja mittels dca konfigurierbart ist, hardcodiert in der Klasse festgelegt sind.

Also dachte ich mir, kein Problem wende ich https://contao.org/methoden-ueberschreiben.html an und überschreibe einfach die eine Methode, übergebe meine Variablen mit ans Template und Problem gelöst. Doch leider ist in diesem Fall die Comments Klasse kein Frontendmodul, wird also nicht über ein Konfigurationsarray geladen.

Liese sich ja auch noch lösen, wenn auch der Ansatz einer sauberen Erweiterbarkeit langsam auf der Strecke bleibt, indem ich einfach die ModulComments überschreibe, den Import von der Comments anpasse. Doch dann müsste ich auch die Klasse des NewsReaders anpassen, da hier auch die Comments Klasse importiert wird. Es wären also drei Klassen anzupassen und zu überschreiben, für eine kleine Erweiterung eines Templates.

Bliebe nur noch die Lösung, eine individuelle Klasse zu erstellen und über die initconfig.php zu laden. Doch was hätte dies dann noch von einer objektorientierten, erweiterbaren Programmierung zu tun? Was passiert, wenn man zwei solche Erweiterungen an einem Modul durchführen muss? In meinem Fall, wie sieht so eine Lösung aus, wenn ich nebher auch noch die Tag-Erweiterung für News nutze, die an sich auch schon die NewsReader erweitert?

Meine Wunschlösung wäre, dass TYPOlight konsequent mit einem Object-Relational-Mapping konzipiert geworden wäre. Dann hätte man einfach folgenden Aufbau umsetzen können

• DCA konfiguriert Tabellenaufbau
• daraus werden die Backendformulare generiert (wird gemacht)
• dient als Grundlage für Datenobjekte
  • Nach einer Datenbankabfrage wird ResultSet an das Datenobjekt übermittelt
  • Erweiterungen können über Konfigurationsarray "Filter" für Datenfelder registrieren. Die Formatierung eines Timestamps zum Datums erfolgt jetzt z.B. über so ein Filter.
  • Zur Ausgabe der Daten des Templates muss lediglich das Datenobjekt übermittelt werden. Während der Iteration führt es die Filterfunktionen aus. Eine doppelte Iteration wird hierdurch überflüssig und das Anpassbarkeit wird bis zum Template durchgezogen.

Ich weiß, dass sich so etwas im Nachhinein nicht mehr einbauen lässt, ohne sämtliche Erweiterungen und Funktionen unbrauchbar zu machen. Daher frage ich mich nach einer brauchbaren Lösung.

• Wie handhabt ihr dies bei euren Entwicklungen?
• Eine Möglichkeit die ich sehe, standardmäßig jedem Template alle Variablen zugänglich zu machen. Für ContentElemente hat Andreas dies ja schon erfolgreich beantragt (http://https://contao.org/issues/1604). Dann würden zwar manche logische Operationen im Template ablaufen, doch damit könnte ich leben.
• Jede Klasse könnte in eiem Arry registriert werden. Ist aber letztlich auch nichts anderes als die intitconfig Geschichte. Für eine spezischische Anpassung möglich, aber für flexible Erweiterungen nicht wirklich von Erfolg gekröhnt

Das sind Gedanken und Anregungen, die mir gekommen sind. Habe ich etwas übersehen, ist dies einfach viel einfacher und ich sehe es nicht? ;-)

[andreas.schempp]

Dein Problem müsste eigentlich mit TYPOlight 2.8.1 behoben sein: http://https://contao.org/issues/1604

[webstar]

Leider nicht, da ich mit der 2.8.1 entwickle. Mir ist das Ticket bekannt und so wie ich es verstanden hatte, ging es hauptsächlich um die Content Elemente. Die von Leo verlinkte Revision http://https://contao.org/projects/t.../revisions/227 zeigt auch, dass Comment nicht betroffen ist. Ich werde daher dieses Ticket dementsprechend ergänzen.

[webstar]

Ich merke gerade, dass ich eh nicht um eine Anpassung der Modulklassen herumkomme. Weil die Daten, die ich verwenden möchte nicht der Commentsklasse übergeben werden ($objConfig enthält nur spezifische Daten). Daher wird meine Lösung für ein allgemeine Erweiterung nicht so einfach ausfallen, wie ich erhofft hatte. Trotzdem ist die Übergabe der Rohdaten sinnvoll, erspart mir eine andere Anpassung für die Kommentarfunktion.