Einbindung von jQuery

cwsoft · 28.10.2016 21:21:30

florian schrieb:

Was ich praktisch fände: Wenn das Frontend-jquery unabhängig vom Backend-jquery wäre. Weil nämlich allerlei Sortierscripte im Backend ältere jQ-Versionen voraussetzen, als z.B. von Bootstrap unterstützt werden.

Würde eher jQuery für WBCE Core und WBCE Userland trennen. Aber wahrscheinlich meinst Du das.

Sprich es gibt ein definiertes jQueryCore mit dem Dinge des WBCE Kerns umgesetzt werden (sortieren, Datumsauswahl ...). Das wird in der Regel eine ältere Version sein, die nur sehr behutsam upgedatet wird.

Das jQuery für das Userland ist wahrscheinlich neuer, bzw. kann für Addons, Templates im Front- und Backend (z.B. Seitenmodule) verwendet werden. Das könnte über ein globales jQuery Objekt oder wie auch immer implementiert werden und sollte die Möglichkeit bieten, verschiedene jQuery Versionen zu laden, bzw. für verschiedene jQuery Plugins bzw. Addons für verschiedene Seiten/Sektionen anpassbar sein. Idealerweise über PHP/Template/JS ansprechbar.

Ginge über ein Modul, einer API ...

stefanek · 28.10.2016 21:40:02

Florian,
die Idee, BE und FE jQuery zu trennen finde ich gar nicht so schlecht.
An sich könnte die
register_frontend_modfiles
Funktion weiterhin erstmal die selben jquery Skripte holen wie das Backend.
Mit der Zeit könnte man dann aber für das Frontend ein Tool bereitstellen, mit dem man sich die jQuery Skripte eigenständig überschreiben kann. (Also einen Standard mitliefern, der eigenständig überschrieben werden kann). Ich betone, dass es gemacht werden könnte. Es sollte auch einstellbar sein, ob und welches CDN verwendet werden soll und die lokalen Dateien nur als Fallback verwendet werden sollen.
Es wäre auch kein Problem Skripte von CDNs auf den Server zu kopieren (übers Modul).

Einen guten Punkt hat auch CWSoft angesprochen, die UI plugins könnte man auch separat haben. Im Backend verwenden wir an sich nur das UI Plugin sortable (für Drag/Drop). Vielleicht noch wo eins, von dem ich nichst weiß.

florian schrieb:

Ansonsten: Vom Prinzip her ist der Ansatz von lib_jquery / library_admin aus Anwendersicht super. Sprich, man installiert ein Modul und lädt dann Mini-Module nach und muss im Idealfall nicht eine Zeile Code schreiben.

Das ist in einigen meiner Module (die ich noch nicht veröffentlicht habe) so:
Du wählst eine Section des Moduls, gehst zur Layoutauswahl und die liefert das gesammte JS/CSS und was sonst noch gebraucht wird (auch eine Sprachdatei, falls vorhanden).
Da muss man dann wirklich keine Zeile Code mehr schreiben, es sei denn, man will das Layout abändern, CSS, JS.

Das bedeutet zwar, dass das selbe jQuery Plugin unter Umständen physikalisch öfter auf dem Server ist, aber vom Handling für den Nutzer ist es viel einfacher.

LibraryAdmin und so weiter. Ich bin da wirklich nicht im Thema. Zu der Zeit als Bianka damit angefangen hat, war ich sehr mit dem OpF Beschäftigt, der auch einige funktionen hat.
Mittlerweile hat sich das CMS wirklich sehr erweitert. Vieles von dem, was LibAdmin auf Umwegen macht, könnte man mit der I/Insert Klasse machen. Doch auch diese Klasse ist noch nicht abgeschlossen. Aber schon ein sehr guter Anfang.

Bianka hat auf jeden Fall sehr viel Erfahrung mit jQuery Einbindung und wahrscheinlich kann sie auch ein Lied davon singen, wie komplex das Thema ist.

Je mehr Infos hier zusammen laufen, um so besser.

Gruß,
Christian

stefanek · 28.10.2016 21:44:20

cwsoft schrieb:

Idealerweise über PHP/Template/JS ansprechbar.
Ginge über ein Modul, einer API ...

Das lässt sich ja leicht machen.
Droplets im pure HTML, I::addJS() im PHP.
Für Templates mit Twig kann man eine eigene Funktion anwenden, oder man verwendet ebenfalls Droplets.
Oder allgemein nur Droplets (oder einen ähnlichen FrontendFilter). Dann ist es einheitlich.

Gruß,
Christian

cwsoft · 28.10.2016 21:50:06

stefanek schrieb:

Florian, die Idee, BE und FE jQuery zu trennen finde ich gar nicht so schlecht.

Ich schon. Seitenmodule haben auch eine "Verwaltungsoberfläche" im Backend, nicht nur im Frontend. Wenn ich ein Modul entwickle, hätte ich jetzt wenig Lust für Frontend jQuery 4.0 zu nutzen, während ich im Backend mit jQuery 1.7 leben muss. Eines der Beispiele wäre z.B. Postits. Das erste Modul für WB welches Ajax (später jQuery) in Front- und Backend verwendete.

Daher würde ich jQuery für WBCE Core (z.B. Pagetree, Default Theme und Template) und Userland trennen, nicht aber für Frontend und Backend. Sprich ein jQuery mit dem alles umgesetzt wird was der WBCE Core braucht und nur über Hacks der Coredateien geändert werden kann. Alles ander ist jQuery Userland mit allen Pipapo.

Beitrag geändert von cwsoft (28.10.2016 21:52:34)

stefanek · 28.10.2016 21:58:42

Ich verstehe jetzt Deine Philosophie mit dem UserLand fürs Backend noch nicht so ganz.
Wie willst Du für das Backend deines Moduls ein anderes jQuery verwenden wie das Theme?

Die jQuery Plugins selbst kann das Modul ja wie bisher im Modul-Ordner mitbringen.

Ich würde nur ungerne alles über Bord werfen was sich bisher bewährt hat.

Gruß,
Christian

(kann erst später antworten, bin kurz weg)

Beitrag geändert von stefanek (28.10.2016 21:59:11)

cwsoft · 28.10.2016 22:09:57

@Stefek. Als Modulentwickler ist mir das Theme egal. Im Normalfall entwickle und teste ich für ein Theme (möglichst das Standardtheme).

Das jQuery im Backend Theme wird ja nicht beeinflusst wenn ich für meine Ansicht z.B. auf der modify.php ein neueres jQuery brauche. AFE hat jahrelang ein neueres jQuery im Backend verwendet, sprich ich hab da mein eigenes jQuery geladen, da ich das Uralt jQuery von WB 2.7 nicht sinnvoll nutzen konnte. Damals einfach über jQuery Kompatibilitätsmodus (NoConflict). Ähnlich im Frontend von Anynews. Dort habe ich eine neuere jQuery Version geladen, damit die Plugins (Slider etc.) vernünftig liefen. Ging mit etwas Verrenkungen seit WB 2.7.

Bleiben wir bei den Modulen ist das kein Problem. Für Backend-Themes muss man halt schauen. Da kann theoretisch jedes ein eigenes jQuery mitbringen. Solange Dinge des WBCE Cores (aktuell PageTree, Sortierung von Seiten/Backend und Datumsauswahl) davon nicht betroffen sind.

Beitrag geändert von cwsoft (28.10.2016 22:22:02)

stefanek · 29.10.2016 00:12:10

Danke für die Ausführungen, Doc.

Allgemein. Ja, in der Tat ein ausführliches Thema.
Ich denke es ist nicht so "dringend", dass wir es sofort lösen müssten.

Lass uns den 1.2.x draussen haben und dann schauen wir in Ruhe weiter.
Trotzdem gut und wichtig es zu besprechen und ich hoffe, es gesellen sich noch weitere Mitstreiter dazu.

Christian

webbird · 31.10.2016 12:05:20

Zur Info: In BC kann man jQuery, jQuery UI und Plugins entweder global in den allgemeinen Einstellungen oder auch seitenbasiert in den Seiteneinstellungen hinzuladen. jQuery Plugins kann man über ein Admin Tool unverändert hochladen. Die einzige Funktionalität, die vom LA noch fehlt, ist das einfache Konfigurieren der Plugins sowie die Bearbeitungsmöglichkeit des Presets. Letzteres kann man zur Not mit dem AFE machen.

attachment.php?item=568&download=1

attachment.php?item=569&download=1

webbird · 31.10.2016 12:15:12

Achso, wir verwenden im BC Core immer die aktuellste jQuery Version, und das, obwohl wir etliche Plugins benutzen, wie z.B. TimePicker, QTip2 etc. Probleme kommen vor, sind aber meist lösbar. Wichtig ist, dass man im Backend AUSSCHLIESSLICH aktiv gepflegte Plugins benutzt, die eine breite Benutzerbasis haben. Also nix Exotisches von 2011. Im allergrößten Notfall gibt's von den jQuery Entwicklern immer noch die *migrate.js, die veralteten Modulen entschwundene Funktionen wieder zur Verfügung stellt.

Also: jQuery Updates sind in der Regel kein größeres Problem, so lange man GENAU darauf achtet, welche Plugins man im BE benutzt.

Ich habe bei uns im Forum einen Beitrag, in dem ich festhalte, welche Plugins wir benutzen und wo ggfs. ein Update aussteht. Bei jedem BC-Update gehe ich die durch.

jQuery 3.x wird es bei uns aber vermutlich auch erst in BC 2.x geben. Das liegt aber eher daran, dass ich keinen so großen Mehrwert sehe, dass ein Update in einer 1.x notwendig wäre. Bisher war der Austausch in 2.x aber im Hinblick auf die BE-Plugins unproblematisch.

norhei · 20.11.2016 01:19:02

Der Stand wie ich das Letzte Mal Jquery geupdatet hatte war. 3.0 War noch early Beta, also unakzeptabel.

Der 2er Strang und der 1er Strang unterschieden sich praktisch auschließlich in der Browserunterstützung.
Da mir breite Browserunterstützung und Compatibilität wichtig sind habe ich als Standard 1.12.0 eingebaut
und auch noch ein Migrate hinzugefügt. Das ist zwar etwas langsamer aber dafür funktioniert noch fast alles.

heise.de schrieb:

Unter der Bezeichnung jQuery Compat 3.0 wird die derzeit unter dem Versionsstrang 1.x entwickelte jQuery-Entwicklung fortgeführt. Mit ihr lassen sich auch ältere Browser wie IE8, Opera 12 und Safari 5 bedienen, weswegen sie für die Entwicklung der meisten Webseiten empfohlen wird.
Unter dem Dach von jQuery 3.x werden die mit jQuery 2.x begonnenen Arbeiten weiterentwickelt.
https://www.heise.de/developer/meldung/ … 40223.html

Das klingt für mich so als sollten wir das Standard Jquery auf jQuery Compat 3.0 Upgraden und weiterhinn Migrate dabeihaben.

Das Globale Kopfdaten Tool schaut angenehm aus , würde das auch unter WBCE Laufen ?

florian · 20.11.2016 09:37:24

Das klingt für mich so als sollten wir das Standard Jquery auf jQuery Compat 3.0 Upgraden und weiterhinn Migrate dabeihaben.

Das Problem sind ja mMn weniger alte Browser als alte jQuery-Plugins, die ihrerseits nicht mehr mit neueren Versionen funktionieren. Ist das Problem mit Migrate gelöst?

Das Globale Kopfdaten Tool schaut angenehm aus , würde das auch unter WBCE Laufen ?

Meinst Du jetzt, ob das BC-Modul unter WBCE läuft (unwahrscheinlich) oder ob WBCE grundsätzlich auch so etwas haben sollte?

webbird · 21.11.2016 17:01:31

Das ist kein Tool sondern Bestandteil des Core, mit entsprechender DB-Tabelle dahinter etc. Also nein.

webbird · 21.11.2016 17:03:51

florian schrieb:

Das Problem sind ja mMn weniger alte Browser als alte jQuery-Plugins, die ihrerseits nicht mehr mit neueren Versionen funktionieren. Ist das Problem mit Migrate gelöst?

Häufig, aber nicht immer. Prinzipiell würde ich veraltete Plugins immer ersetzen, es sei denn, ich kann sie selber pflegen. Denn wenn die keiner pflegt, was ist dann, wenn Exploits bekannt werden? Dass ein Plugin nicht mehr funktioniert ist ja weniger dramatisch als wenn ich mir damit ein Sicherheitsloch aufreiße.

WBCE CMS Forum

#26 28.10.2016 21:21:30

Re: Einbindung von jQuery

#27 28.10.2016 21:40:02

Re: Einbindung von jQuery

#28 28.10.2016 21:44:20

Re: Einbindung von jQuery

#29 28.10.2016 21:50:06

Re: Einbindung von jQuery

#30 28.10.2016 21:58:42

Re: Einbindung von jQuery

#31 28.10.2016 22:09:57

Re: Einbindung von jQuery

#32 29.10.2016 00:12:10

Re: Einbindung von jQuery

#33 31.10.2016 12:05:20

Re: Einbindung von jQuery

#34 31.10.2016 12:15:12

Re: Einbindung von jQuery

#35 20.11.2016 01:19:02

Re: Einbindung von jQuery

#36 20.11.2016 09:37:24

Re: Einbindung von jQuery

#37 21.11.2016 17:01:31

Re: Einbindung von jQuery

#38 21.11.2016 17:03:51

Re: Einbindung von jQuery

Fußzeile des Forums