Ich denke der Entwickler einer Extension sollte in der Extension-Konfiguration eine Checkbox hinterlegen ob jQuery integriert werden sollte oder nicht. Somit lässt sich auch für den nicht TYPO3-Experten die Integration ziemlich simpel handhaben.

Tendenziell würde ich behaupten, dass Lösung eins, wie es auch miestens gehandhabt wird, die richtige Lösung ist. Meine Erfahrung zeigt mir, dass ich mit Lösung zwei weitaus seltener Stress und Nervereien gehabt hätte, doch immer jQuery auskommentieren zu müssen. Insofern bieten die 2 beide ihre Vor und Nachteile. Eine standard nicht angehakte Checkbox wäre mir ein Segen 🙂

Methode drei ist am Besten wenn jeder Extension die jQuery benutzt t3jquery als Abhängigkeit fordert 😉

Was soll an Methode 3 schlecht oder gar ‚gebastel‘ sein. Das hört sich ein bisschen nach ‚Uga, schau mal, was bin ich für ein Kerl. Ich binde das selbst ein.‘
Die meisten Extension, die t3jquery unterstützen, habe auch eine passende jQuery-Datei eingebunden.

Auf jeden Fall auch Methode 3 unterstützen, in dem man ein File „t3jquery.txt“ in der Ext mitliefert.

Zu Methode 3:
Warum Extension Overhead mitschleifen für etwas, was der Core schon kann?
Das ist der totale Irrsinn.
Das sehe ich ohnehin recht oft, dass jemand Extensions schreibt (und damit Ressourcen verbraucht) für Dinge die es schon gibt.
Irgendwann letztens bei nem Neukunden ne Extension gesehen, die ein Menü von Unterseiten baut.
Gnarf.

Lösungsansatz müsste Education sein.

Offizielles Statement der T3A wie man sein jQuery zu laden hat.
includeJSlibs benutzen und gut ist.
Dafür ist der JS Loader ja schließlich da.

Eine Kombi aus 1 und 3 wäre doch nett! Methode 1 sollte konfigurierbar sein aber defaultmäßig deaktiv und für Methode 3 natürlich die entsprechenden Abhängigkeiten innerhalb einer beiliegenden „t3jquery.txt“ regeln und nicht über eine Abhängigkeit zur t3jquery-Ext… Da bleiben doch keine Wünsche offen!

Ich bin für Methode 3, damit wird dann jquery nur 1x importiert und nicht x-mal. Problematisch wird es natürlich, wenn man eine bestimmte jQuery-Version braucht, aber dann ist es sowieso problematisch.

@Matthias: Nun ich bau regelmäßig Menüs mit Extensions, weils einfach in manchen Fällen leichter geht und bevor ich in 300 Zeilen TS irgendwelche Konstrukte habe, die ich a) nicht versteh, b) sicher nicht performanter sind und c) sowieso keiner mehr warten kann, dann lieber PHP. Extensions baut man auch nicht mit TS 😉

Menues per Extension? Warum tut man so etwas? TS bietet für so ziemlich alles die Passenden Werkzeuge und gerade komplexe Menues lassen sich doch mit TS mit weitaus weniger Code und weniger zeit umsetzen als über eine eigene Extension und sind weitaus schneller nach zu vollziehen als erstmal ne Extension zu inspizieren. Klingt für mich alles eher nach „Keine lust mich mit TS zu beschäftigen, Spagetticode in PHP tut es ja auch.“. Mal abgesehen davon, dass die Nummer mit dem TS halt auch nen tieferen Sinn hat, was auch die spätere Wartbarkeit an geht, da zum Beispiel ein Integrator nicht zwingend gleichzeitig Extension-Entwickler sein muss. Von daher halte ich diese Vorgenhensweise nicht wirklich für Zielführend und im Sinne des TYPO3 Konzeptes. ^^

Aber zurück zum Thema. Optimal wäre es per TS. Das Page Objekt bietet in Sachen JS da umfassende Möglichkeiten. Js im Header und im Footer ein zu binden und das auch noch nach Anwendungsdateien und Libs getrennt. page.includeJSlibs, page.includeJSFooterlibs wären hier die passenden Kandidaten um jQuery so ein zu binden, dass jeder weis was los ist und, dass man es überschreiben kann. Auch externe Libs aus einem CDN lassen sich so wunderbar einbinden. Das ganze bringt auch noch den Vorteil, dass man das gesamte JS in einer Hierarchie hat und so sehr genau Einfluss auf die Reihenfolge der Einbindung nehmen kann. Zumal es auch einige Extensions gibt die darüber alles JS in einer Datei zusammen fassen und komprimieren. Leider gibt es auch immer wieder Extensions die Js-Dateien auch über fragwürdige Konstrukte in ihren PHP-Klassen einbinden, an die man dann nur über eine eigene Erweiterung oder Pfusch an der Extension ran kommt. Optimal finde ich es jedenfalls per TS weil ich so im Objectbrowser einen direkten Überblick bekomme was alles eingebunden ist und wie ich es überschreiben, oder raus nehmen kann. 🙂 Da ist das dann blos noch eine Sache von ein paar Minuten wenn es mal Probleme gibt 🙂