[SPIP Zone] [Spip-zone-commit] r108672 - _plugins_/crayons/branches/v3/js

cerdic · Février 6, 2018, 8:35

Hello Didier,

puisque tu dois refaire tes commits j’en profite pour te donner un peu d’historique :

ce n’est pas parce que jQuery n’est pas natif dans SPIP qu’on a dans le plugin crayons une version de jQuery renomée, car c’était déjà le cas quand le plugin a été créé.

C’est pour 2 raisons :
* la première est qu’on est jamais sur de ce que le squelette public va embarquer ou non jQuery ni dans quelle version
* la seconde est d'assurer la compatibilité trans-versions de SPIP

En embarquant sa propre version de jQuery et en le chargeant sous le nom de cQuery le plugin est certain de qu’il aura jQuery disponible, dans la bonne version, sans problème de compatibilité.

Avant donc de tout sabrer ça peut-être utile de poser des questions aux auteurs du plugin ou même sur la liste de la zone ou de fouiller un peu l’historique du plugin pour comprendre les choix techniques qui ont été fait, pour quelles raisons, et avoir un peu de background.

Ici je pense qu’il serait pertinent de garder le principe d’un jQuery spécifique au plugin, renommé, comme ça a été fait.

--
Cédric

On 28 janv. 2018 à 19:34 +0100, spip-zone-commit@rezo.net, wrote:

Author: p@henix.be
Date: 2018-01-28 19:34:11 +0100 (Sun, 28 Jan 2018)
New Revision: 108672

Removed:
_plugins_/crayons/branches/v3/js/jquery.js
Log:
ça fait longtemps que jQuery est natif

Details: Connexion · GitLab

_______________________________________________
Spip-zone-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone-commit

Debondt_Didier · Février 6, 2018, 9:16

Bonjour Cédric,

* la première est qu’on est jamais sur de ce que le squelette public va embarquer ou non jQuery ni dans quelle version

Cette remarque m'a déjà été faite par RealET, quelques commit plus loin
j'ai corrigé avec ceci :

Après, peut être que ce n'est pas suffisant ?

* la seconde est d'assurer la compatibilité trans-versions de SPIP

Oui, mais cette refonte n'est prévue que pour SPIP 3.2. Les autres
versions de SPIP continueront d'utiliser l'ancienne version.

Ici je pense qu’il serait pertinent de garder le principe d’un jQuery
spécifique au plugin, renommé, comme ça a été fait.

Le but essentiel de ma refonte est de supprimer les librairies doublons.
Si je dois garder une version de jQuery, autant ne rien faire...

cedric@yterium.com writes:

Hello Didier,

puisque tu dois refaire tes commits j’en profite pour te donner un peu d’historique :

ce n’est pas parce que jQuery n’est pas natif dans SPIP qu’on a dans le plugin crayons une version de jQuery renomée, car c’était déjà le cas quand le plugin a été créé.

C’est pour 2 raisons :
* la première est qu’on est jamais sur de ce que le squelette public va embarquer ou non jQuery ni dans quelle version
* la seconde est d'assurer la compatibilité trans-versions de SPIP

En embarquant sa propre version de jQuery et en le chargeant sous le nom de cQuery le plugin est certain de qu’il aura jQuery disponible, dans la bonne version, sans problème de compatibilité.

Avant donc de tout sabrer ça peut-être utile de poser des questions aux auteurs du plugin ou même sur la liste de la zone ou de fouiller un peu l’historique du plugin pour comprendre les choix techniques qui ont été fait, pour quelles raisons, et avoir un peu de background.

Ici je pense qu’il serait pertinent de garder le principe d’un jQuery spécifique au plugin, renommé, comme ça a été fait.

cerdic · Février 6, 2018, 4:54

On 6 févr. 2018 à 10:16 +0100, Debondt Didier <p@henix.be>, wrote:

Bonjour Cédric,

> * la première est qu’on est jamais sur de ce que le squelette
> public va embarquer ou non jQuery ni dans quelle version

Cette remarque m'a déjà été faite par RealET, quelques commit plus
loin
j'ai corrigé avec ceci :

Connexion · GitLab

Après, peut être que ce n'est pas suffisant ?

> * la seconde est d'assurer la compatibilité trans-versions de
> SPIP

Oui, mais cette refonte n'est prévue que pour SPIP 3.2. Les autres
versions de SPIP continueront d'utiliser l'ancienne version.

Mais la version de jQuery ne dépend pas uniquement de la version de SPIP, certains projets fournissent une version plus récente quand ils en ont besoin, ce qui peut amener à des ruptures de compatibilité.
Et quid de la suite ? Quand SPIP 3.3 sortira puis SPIP 3.4 cela veut dire qu’on aura une branche du plugin par version de SPIP, potentiellement ?

> Ici je pense qu’il serait pertinent de garder le principe d’un
> jQuery
> spécifique au plugin, renommé, comme ça a été fait.

Le but essentiel de ma refonte est de supprimer les librairies
doublons.
Si je dois garder une version de jQuery, autant ne rien faire…

C’est dans l’ADN du plugin Crayons que d’être robuste vis à vis du squelette et de comment il est construit et de garantir qu’il aura toujours sa bonne version de jQuery pour fonctionner.

Peut-être ça veut dire qu’il faudrait recoder tout le JS du plugin pour s’affranchir totalement de jQuery et le faire fonctionner en pur vanillaJS, peut-être qu’il faut abandonner cette idée de robustesse, ou peut-être qu’au contraire c’est important qu’il continue à fonctionner comme il le faisait.

Tu veux supprimer les librairies doublons, pourquoi pas, mais dans quel but ?
Est-ce une pénalité de performance problématique dans la mesure où elle touche uniquement les admins connectés et jamais les visiteurs publics ?
Est-ce un prix trop important à payer pour avoir de la robustesse ?
Qui va gérer le surcroit de support que la baisse de robustesse va entraîner ?

Dans tous les cas c’est une orientation assez majeure du développement du plugin et la moindre des choses est de soulever la question avant, non ?

--
Cédric

Debondt_Didier · Février 6, 2018, 10:07

Mais la version de jQuery ne dépend pas uniquement de la version de SPIP, certains projets fournissent une version plus récente quand ils en ont besoin, ce qui peut amener à des ruptures de compatibilité.
Et quid de la suite ? Quand SPIP 3.3 sortira puis SPIP 3.4 cela veut dire qu’on aura une branche du plugin par version de SPIP, potentiellement ?

Donc si je suis cette logique, tous les plugins SPIP qui utilisent
jQuery doivent embarquer "la version qui va bien", la renommer et la charger en plus
de celle fournie par SPIP ?

Je ne vois pas ou on va avec cette logique...
Pour les autres plugins, cela ne pose pas de problème. Je ne comprend
pas pourquoi les crayons serait différent de ce point de vue.

Tu veux supprimer les librairies doublons, pourquoi pas, mais dans quel but ?
Est-ce une pénalité de performance problématique dans la mesure où
elle touche uniquement les admins connectés et jamais les visiteurs
publics ?

Cela créer des bug, notament quand on utilise #FILTRE{minifier_js}

Je trouve aussi que cela rend le plugin inutilement complexe et que ça
bloque les évolutions. On a pas envie de le faire évoluer...

Remettre le code a plat, cela ne me semble pas être une mauvaise idée
pour le futur :).

Dans tous les cas c’est une orientation assez majeure du développement du plugin et la moindre des choses est de soulever la question avant, non ?

Bien entendu. Ce n'est pas comme si j'avais directement remplacé les
crayons par ma version. Je ne fait que proposer des changements de
manière concrète.
Je t'accorde que j'ai fait une bêtise sur l'historique du plugin, mais
ce n'est qu'un malheureux accident.

cedric@yterium.com writes:

On 6 févr. 2018 à 10:16 +0100, Debondt Didier <p@henix.be>, wrote:

Bonjour Cédric,

> * la première est qu’on est jamais sur de ce que le squelette
> public va embarquer ou non jQuery ni dans quelle version

Cette remarque m'a déjà été faite par RealET, quelques commit plus
loin
j'ai corrigé avec ceci :

Connexion · GitLab

Après, peut être que ce n'est pas suffisant ?

> * la seconde est d'assurer la compatibilité trans-versions de
> SPIP

Oui, mais cette refonte n'est prévue que pour SPIP 3.2. Les autres
versions de SPIP continueront d'utiliser l'ancienne version.

Mais la version de jQuery ne dépend pas uniquement de la version de SPIP, certains projets fournissent une version plus récente quand ils en ont besoin, ce qui peut amener à des ruptures de compatibilité.
Et quid de la suite ? Quand SPIP 3.3 sortira puis SPIP 3.4 cela veut dire qu’on aura une branche du plugin par version de SPIP, potentiellement ?

> Ici je pense qu’il serait pertinent de garder le principe > d’un
> jQuery
> spécifique au plugin, renommé, comme ça a été fait.

Le but essentiel de ma refonte est de supprimer les librairies
doublons.
Si je dois garder une version de jQuery, autant ne rien faire…

C’est dans l’ADN du plugin Crayons que d’être robuste vis à vis du squelette et de comment il est construit et de garantir qu’il aura toujours sa bonne version de jQuery pour fonctionner.

Peut-être ça veut dire qu’il faudrait recoder tout le JS du plugin pour s’affranchir totalement de jQuery et le faire fonctionner en pur vanillaJS, peut-être qu’il faut abandonner cette idée de robustesse, ou peut-être qu’au contraire c’est important qu’il continue à fonctionner comme il le faisait.

Tu veux supprimer les librairies doublons, pourquoi pas, mais dans quel but ?
Est-ce une pénalité de performance problématique dans la mesure où elle touche uniquement les admins connectés et jamais les visiteurs publics ?
Est-ce un prix trop important à payer pour avoir de la robustesse ?
Qui va gérer le surcroit de support que la baisse de robustesse va entraîner ?

Dans tous les cas c’est une orientation assez majeure du développement du plugin et la moindre des choses est de soulever la question avant, non ?

Mist_GraphX · Février 7, 2018, 6:28

Le 06/02/2018 à 23:07, Debondt Didier a écrit :

Je ne vois pas ou on va avec cette logique...
Pour les autres plugins, cela ne pose pas de problème. Je ne comprend
pas pourquoi les crayons serait différent de ce point de vue.

Hello,

En toute amitié, je pense que la soit tu fais preuve de mauvaise fois sur ce coup ou ne veut pas comprendre ce que t'explique cedric !!

La pour le coup des crayons risquer de tout peter ou de se prendre le chou, pour quoi 75 kb mis en cache juste pour un admin en plus ??

si tu veux optimiser : tu pourrais te pencher sur le cas de jquery_ui qui embarque tout depuis spip 3.2 ce qui est beaucoup plus problematique au niveau performance ! En fin de mon avis c'est plus important …… moi j'ai rétablis la version précédente pour le moment j'ai gagné 125 kb par page… et pas que pour les connectés

m2sous

--
Bonne journée
Arnaud B. (Mist. GraphX)

JLuc · Février 7, 2018, 7:51

Le 07/02/2018 à 07:28, Mist. GraphX a écrit :

Le 06/02/2018 à 23:07, Debondt Didier a écrit :

Pour les autres plugins, cela ne pose pas de problème. Je ne comprend
pas pourquoi les crayons serait différent de ce point de vue.

En toute amitié, je pense que la soit tu fais preuve de mauvaise fois sur ce coup ou ne veut pas comprendre ce que t'explique cedric !!

Méthodologiquement la mauvaise foi ne doit être envisagée vraiment qu'en dernier recours
(c'est du "ad hominem")

Sans mauvaise foi moi non plus j'ai pas compris pourquoi faire un cas particulier des crayons,
car dans l'absolu les arguments sont valables également pour les autres plugins.

Tu peux certainement nous expliquer ?

si tu veux optimiser : tu pourrais te pencher sur le cas de jquery_ui qui embarque tout depuis spip 3.2 ce qui est beaucoup plus problematique au niveau performance ! En fin de mon avis c'est plus important …… moi j'ai rétablis la version précédente pour le moment j'ai gagné 125 kb par page… et pas que pour les connectés

Tu utilises donc la version SPIP 3.1 du plugin jquery UI (1.11.4) sur un spip 3.2 ?

JL

Mist_GraphX · Février 7, 2018, 9:12

j'ai commencé par "en toute amitié" hein ,

j'admets en me relisant que ça peut être mal pris, si c'est le cas je m'en excuse

Le 07/02/2018 à 08:51, JLuc a écrit :

Tu utilises donc la version SPIP 3.1 du plugin jquery UI (1.11.4) sur un spip 3.2 ?

oui, j'ai testé sur un ou deux projets ça passe pour le moment

la on parle de js que tout le monde charge, avant je chargeais 10 à 15 kb que j'utilisais réellement, maintenant 509 ko (non compressé j'entends) que j'utilise pas forcément… j'en ai déjà parlé, avec marcimat sur irc c'est due au dernières évolutions de la lib et problématique de rétablir l'ancien fonctionnement (ce que je comprends, j'ai regardé c'est effectivement compliqué, il on changé la structure et privilégient les outils de build).

l'autre solution actuellement est de surcharger le fichier jquery.ui avec sa version a soi compilé avec juste le necessaire…comme on pourrait le faire avec jquery…

en fait si on fait pas du site "industrialisé", la méthode de création de theme/squelettes la plus simple est de tout compiler/construire a la demande et donc de ne pas forcément embarquer la version livré avec spip soit de jquery.ui ou de jquery,
de ne pas forcément activer un plugin pour avoir des onglet en js ou autre surtout quand on va tout surcharger ensuite,
bref dans le cas du sur-mesure on est souvent amener a embarquer ses propres librairies (par ex version d'un framework x necessite jquery 4), indépendament des versions embarquées de spip necessaires au bon fonctionnement de la partie privé …

d'ou le fait que l'on peut donc actuellement et depuis toujours surcharger jquery dans /javascript/jquery … comme dit avant c'est historique , avant spip 3 la version de jquery était un peut a la bourre et ça m'est régulièrement arrivé d'utiliser cette solution en partie front.

ce qu'expliquait cedric, c'est que dans ce cas, si j'ai surchargé pour la partie front ma version de jquery, c'est celle qui sera utilisé par les crayons, d'ou le fait que crayons a toujours embarqué sa version perso ça évite des cassages potentiels aussi a chaque changement de jquery. Et comme ce n'est que les rédac/connecté c'est un moindre mal… les sites ayant surchargé en front le js continuerons de marcher et crayons aussi meme en cas d'upgrade de spip… ceci garanti de pouvoir mettre a jour le noyau de spip sans pour autant se retaper du js, des styles, des bugs … bref des interventions qui ne font pas forcément parti d'un forfait mise a jour ^^…

Après la question c'est : qu'est ce qui est utilisé de jquery dans crayons ? doit on embarquer la totale ? pourquoi ne pas utiliser un outil de build pour faire une version ultra light avec juste ce qu'il faut ?

--
Bonne journée
Arnaud B. (Mist. GraphX)

Debondt_Didier · Février 7, 2018, 9:20

Hello,

En toute amitié, je pense que la soit tu fais preuve de mauvaise fois
sur ce coup ou ne veut pas comprendre ce que t'explique cedric !!

Point de mauvaise foi ici, je comprend parfaitement de quoi parle
Cédric. Je fait simplement remarqué que sont raisonnement diffère de ce
qui est généralement fait.
Cela ne me semble pas incohérent comme raisonnement.

La pour le coup des crayons risquer de tout peter ou de se prendre le
chou, pour quoi 75 kb mis en cache juste pour un admin en plus ??

En dehors de l'historique, je n'ai rien cassé. Et j'ai invité
publiquement toutes les bonnes volontés à tester mes changements.

Je ne cherche pas a économiser de la bande passante, mais a "moderniser"
le code de ce plugin.

Mist. GraphX <arnaud.berard@mister-graphx.com> writes:

Le 06/02/2018 à 23:07, Debondt Didier a écrit:

Je ne vois pas ou on va avec cette logique...
Pour les autres plugins, cela ne pose pas de problème. Je ne comprend
pas pourquoi les crayons serait différent de ce point de vue.

Hello,

En toute amitié, je pense que la soit tu fais preuve de mauvaise fois
sur ce coup ou ne veut pas comprendre ce que t'explique cedric !!

La pour le coup des crayons risquer de tout peter ou de se prendre le
chou, pour quoi 75 kb mis en cache juste pour un admin en plus ??

si tu veux optimiser : tu pourrais te pencher sur le cas de jquery_ui
qui embarque tout depuis spip 3.2 ce qui est beaucoup plus problematique
au niveau performance ! En fin de mon avis c'est plus important …… moi
j'ai rétablis la version précédente pour le moment j'ai gagné 125 kb par
page… et pas que pour les connectés

m2sous

cerdic · Février 7, 2018, 9:36

On 7 févr. 2018 à 10:20 +0100, Debondt Didier <p@henix.be>, wrote:

Hello,

> En toute amitié, je pense que la soit tu fais preuve de mauvaise
> fois
> sur ce coup ou ne veut pas comprendre ce que t'explique cedric
> !!

Point de mauvaise foi ici, je comprend parfaitement de quoi parle
Cédric. Je fait simplement remarqué que sont raisonnement diffère
de ce
qui est généralement fait.
Cela ne me semble pas incohérent comme raisonnement.

Il n’y a pas de généralité : certains plugins ont une branche par version de SPIP, d’autres ont des branches multiversions et ne branchent qu’en cas de rupture de compatibilité, d’autres prennent un soin particulier à assurer la compatibilité multi-version avec une seule version du plugin.

Le plugin crayon est un outil d’admin dont on attends qu’il continue de fonctionner même si le squelette public évolue, et de ce point de vue il y a eu un choix technique fort initial.
L’ignorer et le jeter à la poubelle sans poser de question est assez peu communautaire comme méthode.

> La pour le coup des crayons risquer de tout peter ou de se
> prendre le
> chou, pour quoi 75 kb mis en cache juste pour un admin en plus
> ??

En dehors de l'historique, je n'ai rien cassé. Et j'ai invité
publiquement toutes les bonnes volontés à tester mes changements.

Je ne cherche pas a économiser de la bande passante, mais a
"moderniser"
le code de ce plugin.

Pourquoi pas, mais encore une fois je dis qu’un changement majeure d’orientation dans le développement d’un plugin, en particulier un plugin aussi utilisé que les crayons, mérite d’être discuté avant, avec ses auteurs/mainteneurs ou au moins sur la liste.

Et j’aura tendance à penser que si on veut vraiment moderniser le vrai bon choix aujourd’hui serait de faire en sorte que tout son JS soit vanilla, indépendant de toute librairie javascript, ce qui est quelque chose qui n’était pas possible il y a 10 ans.

La question est ouverte en tout cas

--
Cédric

Mist_GraphX · Février 7, 2018, 10:33

Le 07/02/2018 à 10:36, cedric@yterium.com a écrit :

Et j’aura tendance à penser que si on veut vraiment moderniser le vrai bon choix aujourd’hui serait de faire en sorte que tout son JS soit vanilla, indépendant de toute librairie javascript, ce qui est quelque chose qui n’était pas possible il y a 10 ans.

+1 surtout qu'il y'a plétor de libs qui font de l'edition directe via des controlleurs css, chose qu'il n'y avait pas aussi à l'époque…

Le 07/02/2018 à 10:20, Debondt Didier a écrit :

Je ne cherche pas a économiser de la bande passante, mais a "moderniser"
le code de ce plugin.

J'ai bien lu et merci du temps que tu y consacre… n'y vois pas la une critique mais juste un justification des effets de bords possibles, que je vois et surtout en fonction de MES utilisations de spip (un peut border-line certes de temps a autre, mais je dois pas être tout seul …).

Après dans le cadre d'un refactorisation, sur les utilisations que j'ai faites de crayons, c'est surtout l'interface coté publique qui est parfois un peut tricky a gérer suivant les sites et le contexte css, le types de périphériques (les crayons en version mobile, au scroll c'est assez dur a gérer …), et effectivement ça m'est arrivé de devoir surcharger pour changer certaines parties du markup généré …

Je testerais et te ferais un retour (d'ailleurs comme dit précédemment c'était le but de mon message ^^), mais le seul site ou j'utilise les crayons n'est déjà pas passé en 3.2 a cause du javascript lol (** humour mais véridique**).

--
Bonne journée
Arnaud B. (Mist. GraphX)