21 Reaktionen zu “Die Krux mit dem jQuery”

Kommentare abonnieren (RSS) oder TrackBack URL

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.

Andreas Becker am 12. April 2013 um 13:47

Methode 1 gefällt mir auch am Besten. Vielleicht jQuery in ein extra static template einbauen, dann kann man bei der Installation gleich entscheiden, ob man die mitgelieferte jQuery Version nutzen möchte.

Peter Kraume am 12. April 2013 um 13:55

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 🙂

Dirk D am 12. April 2013 um 14:07

Was vielleicht auch ein interessanter, wenngleich – bedingt durch Extbase und Fluid – noch nicht so offensichtlicher, Ansatz sein kann:

Zuhilfenahme eines ViewHelpers für die Einbindung von jQuery:
https://bitbucket.org/sotastudio/typo3.extbase.flexslider/src/908d8807fc10/Classes/ViewHelpers/AddJQueryViewHelper.php?at=master

In dem ViewHelper prüfe ich auf Präsenz von t3jquery. Ist die Ext nicht da, wird ein Alternativ-File (von der Ext bereitgestellt) eingebunden.

Wem das alles nicht passt, kann in meiner Extension bspw. einfach den ViewHelper-Aufruf entfernen und das Ganze selbst einbinden:
https://bitbucket.org/sotastudio/typo3.extbase.flexslider/src/908d8807fc10/Resources/Private/Partials/ResourceFiles.html?at=master#cl-3

Für eine vereinfachte Einbindung von CSS und JS habe ich ebenfalls einen ViewHelper gebaut:
https://bitbucket.org/sotastudio/typo3.extbase.flexslider/src/908d8807fc10/Classes/ViewHelpers/AddCssJsViewHelper.php?at=master

Andy am 12. April 2013 um 14:12

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

Christopher am 12. April 2013 um 14:15

Es kommt halt sehr darauf an wer hier integriert und wen es sich richtet.

Je unbedarfter die Leute, desto besser sowas wie Nummer 3. Je mehr das Projekt als Projekt und nicht als Bastelei gemacht wird, desto eher ist man froh dass gar nix eingebunden wird und man das selber macht weil die Chance, dass es dem eigenem Workflow entspricht halt dementsprechend klein ist.

Georg Ringer am 12. April 2013 um 17:00

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.

Stephan Bauer am 12. April 2013 um 22:40

Ich finde es nervig, wenn ich jedes mal bei allen möglichen Extensions erst die Nutzung des eigenen jquery-includes deaktivieren muss. Wenn man das bei einer Extension in den constants einfach deaktivieren kann, schön.

Thiel am 13. April 2013 um 17:54

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

Andreas am 13. April 2013 um 19:18

Ich mache das auch immer via Extension-Konfiguration, dann kann man gleich beim Installieren entscheiden, ob (und welche Version von) jQuery eingebunden werden soll.

Patrick am 13. April 2013 um 23:07

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.

Mathias Schreiber am 14. April 2013 um 09:12

gerade, da es soviele möglichkeiten gibt jquery und die tools einzubinden finde ich t3jquery eigentlich ziemlich gut, wird eben dieses unterstützt kann man sich nämlich eine library bauen, die genau auf die extensions passt. deswegen sollte die info datei dafür einfach mitgeliefert werden.
t3jquery will genau das erreichen was immer bemeckert wird, nämlich einen konsistenten weg zum einbauen von jquery und den zugehörigen tools geben.
sicherlich ist es sinnlos bei extensions ab 4.7 o.ä. jquery mitzuliefern, aber auch die jQueryUI sachen sollten einfach schon im core liegen. evt. sollte es einfach ein include static im core für die tools und jquery geben 😉

Kay S. am 14. April 2013 um 20:48

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!

Der Dude am 15. April 2013 um 08:34

In dem neuen TYPO3 6.0 gibt es doch die Funktion config.javascriptLibs … das scheint mir der vernünftigste Lösungsansatz zu sein mit solchen JS-Libraries umzugehen. Vielleicht sollte man mal eine Extension ins TER stellt, dass diese Funktionalität – 1:1 auch für ältere TYPO3-Versionen zur Verfügung stellt.

Und dann können entsprechende Extensions perfekt darauf basiert die ihre notwendigen Frameworks einbinden.

Armin Vieweg am 15. April 2013 um 08:40

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.

hauke am 15. April 2013 um 13:00

also im neuen Core gäbe es dann Unterstützung für requireJS, damit kann man sich einen Abhängigkeits-/Modul-Lade-Baum basteln, so daß auf der jeweiligen TYPO3 Seite wirklich nur die JS-Dateien und Libraries geladen werden, die man dort benötigt.
Warum sind überflüssige Zeilen Javascript-Code schlecht ? Weil der Browser sie jedes Mal interpretieren muss beim Seitenaufruf.
Moderne Browser und ihre JIT-Engines sind da ziemlich performant, aber ein IE 8 oder ein alter FF können dadurch DEUTLICH durchhängen… also besser schlank und modular JS laden und vor dem Ausliefern evtl. noch SINNVOLL mergen und komprimieren.

gast am 15. April 2013 um 15:55

@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 😉

Georg Ringer am 17. April 2013 um 19:50

@Georg: Menüs in Typoscript bauen ist schnell und einfach, auch komplexe Konstrukte … Leider vergessen PHP Programmierer oft, in Enterprise-Dimensionen zu denken und daran, daß ihre Extension in verschiedenen Sprachen, auf verscihedenen Domains, in Workspaces etc. laufen muss.

Erst wenn ich als PHP-Entwickler das alles innerhalb von TYPO3 verstanden habe, kann ich anfangen Extensions zu entwickeln… wie oft sucht man nach einem Fehler auf PHP Ebene, den man hätte mit Typoscript vermeiden können…

gast am 18. April 2013 um 17:06

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 🙂

Björn am 28. April 2013 um 01:22

Ich bevorzuge 1. Aber viel schlimmer ist, wie viele ihr eigenes JavaScript einbinden. Das sollte mal in die Development Guides aufgenommen werden. Niemals Hardcoded bitte, am besten noch die PHP-Arrays direkt bearbeitet. Und immer alles deaktivierbar / anpassbar, damit eben auch andere JavaScript-Frameworks die Aufgaben übernehmen können.

Alle sollten so wie die TYPO3 CMS-Einstellungen für Lightboxes sein. Sehr angenehm – aus Entwicklersicht.

Hauke am 13. September 2013 um 21:03
Trackbacks & Pingbacks

[…] And finally here a link to an article discussing the best way of how to include Javascript in TYPO3 extensions (unfortunately only in German): Die Krux mit dem jQuery. […]

Ein Kommentar hinterlassen


 Name


 Mail (wird nicht veröffentlicht)


 Website

Bitte beachten sie, dass ihr Kommentar möglicherweise erst freigeschaltet werden muss.

Kategorien

Archiv (Quick)

April 2017
M D M D F S S
« Mrz    
 12
3456789
10111213141516
17181920212223
24252627282930