On est pas censé utiliser 2 jQuery sur le meme site, non plus …
Il faut règler la compat d’un cote ou de l’autre pour utiliser une unique version.
J’avais ajouté ma propre version parce que la syntaxe de certains sélecteurs avait changé et ils ne fonctionnaient plus avec l’ancienne version incluse dans SPIP.
L’ancienne version ? dans la SVN ?
hum j’ai du mal a comprendre…
Tu n’aurais pas fait le contraire ? ajouté une veille version ?
Avec un nombre croissant de sites et plugins utilisant différentes versions de jQuery, le problème n’est sans doute pas isolé.
si, car spip et releasé avec une version donnée de jquery, et qui sert de référence.
Cédric
On est pas censé utiliser 2 jQuery sur le meme site, non plus …
Il faut règler la compat d’un cote ou de l’autre pour utiliser une unique version.
J’avais ajouté ma propre version parce que la syntaxe de certains sélecteurs avait changé et ils ne fonctionnaient plus avec l’ancienne version incluse dans SPIP.
L’ancienne version ? dans la SVN ?
Bin oui, j’avais mis à jour mon code perso pour jQuery 1.3 avant que ce soit intégré dans la SVN.
hum j’ai du mal a comprendre…
Tu n’aurais pas fait le contraire ? ajouté une veille version ?
Non, non.
Avec un nombre croissant de sites et plugins utilisant différentes versions de jQuery, le problème n’est sans doute pas isolé.
si, car spip et releasé avec une version donnée de jquery, et qui sert de référence.
Elle sert de référence pour les développement du core ou de plugins ne fonctionnant qu’à partir de cette version du core.
Mais quid des plugins qui ont été créés auparavant, et fonctionnent toujours avec SPIP SVN, sauf au niveau des sélecteurs jQuery. Faut-il qu’ils fassent une version de plugin par version de SPIP, plutôt qu’inclure leur propre version de jQuery qui leur permet de n’avoir qu’une seule version de plugin ?
Et pour ceux qui créent leurs sites en commençant par une maquette HTML/CSS/JS avec la dernière version de jQuery, puis veulent intégrer une version stable de SPIP, pas forcément à jour niveau jQuery ?
Et pour ceux qui créent leurs sites en commençant par une maquette
HTML/CSS/JS avec la dernière version de jQuery, puis veulent intégrer une
version stable de SPIP, pas forcément à jour niveau jQuery ?
Surtout s'il faut que ça tourne sous Netscape Navigator 3.0 !!
Je ne crois pas que cette discussion concerne SPIP. On fournit un
environnement pour faire des sites pas un système d'intelligence
artificielle.
jQuery a cassé sa compat ascendante pour une raison précise
(introduction d'un moteur commun à de nombreuses librairies
javascript), et pour ceux qui utilisent ça à fond : il faut accepter
de suivre un peu, ou alors forker le projet jQuery (et faire mieux).
Bonne chance !
Et pour ceux qui créent leurs sites en commençant par une maquette
HTML/CSS/JS avec la dernière version de jQuery, puis veulent intégrer une
version stable de SPIP, pas forcément à jour niveau jQuery ?
Surtout s'il faut que ça tourne sous Netscape Navigator 3.0 !!
Là tu ajoutes un niveau de complexité supplémentaire.
Je ne crois pas que cette discussion concerne SPIP. On fournit un
environnement pour faire des sites pas un système d'intelligence
artificielle.
Je n'ai jamais dit ça. Je demandais si jQuery permettait d'utiliser deux versions simultanément, je n'ai demandé aucune évolution de SPIP à ce niveau.
jQuery a cassé sa compat ascendante pour une raison précise
(introduction d'un moteur commun à de nombreuses librairies
javascript), et pour ceux qui utilisent ça à fond : il faut accepter
de suivre un peu, ou alors forker le projet jQuery (et faire mieux).
Bonne chance !
C'est bien ce que vous avez fait pour Crayons, non ?
Ne pourrait-il pas utiliser le jQuery de SPIP avec #INSERT_HEAD ?
1) Je ne comprends pas ce que tu ne comprends pas. Quand je parle
d'une page qui n'a pas jQuery elle n'a probablement pas #INSERT_HEAD
non plus.
2) je ne comprends pas ce que tu cherches à faire : si les crayons
marchent très bien et suscitent peu de rapport de bugs, c'est en
partie grâce à ce stratagème. Mais il n'est pas généralisable à la
partie "publique" de tous les sites, car il est quand même un peu
coûteux en perfs (on charge deux fois jquery, après tout).
Maintenant si ta suggestion c'est de changer les crayons pour qu'ils
utilisent jQuery quand il est présent, euh... tu appelles ça
gastero-crayons et tu assures le SAD...
Ne pourrait-il pas utiliser le jQuery de SPIP avec #INSERT_HEAD ?
1) Je ne comprends pas ce que tu ne comprends pas.
Dites, les autres, prévenez-nous si notre discussion vous dérange...
Quand je parle d'une page qui n'a pas jQuery elle n'a probablement pas #INSERT_HEAD non plus.
Mais le pipeline affichage_final ne pourrait-il pas détecter qu'on en a besoin, peut-être avec un "marqueur" spécifique posé par Crayons, et ainsi charger le jQuery de SPIP ?
2) je ne comprends pas ce que tu cherches à faire : si les crayons
marchent très bien et suscitent peu de rapport de bugs, c'est en
partie grâce à ce stratagème. Mais il n'est pas généralisable à la
partie "publique" de tous les sites, car il est quand même un peu
coûteux en perfs (on charge deux fois jquery, après tout).
Cela ne me choque pas plus que ça que jQuery soit chargé deux fois, ce que je faisais aussi de toute façon. J'essaie seulement de réfléchir, à voix haute tant qu'à faire pour recueillir d'autres avis, à l'éventuelle possibilité d'optimiser ça.
Si je réfléchi trop fort, on peut s'arrêter là...
Maintenant si ta suggestion c'est de changer les crayons pour qu'ils
utilisent jQuery quand il est présent, euh... tu appelles ça
gastero-crayons et tu assures le SAD...
Mais le pipeline affichage_final ne pourrait-il pas détecter qu'on en a
besoin, peut-être avec un "marqueur" spécifique posé par Crayons, et ainsi
charger le jQuery de SPIP ?
Ce genre de pratique pour insérer un script dans le head en fonction
de la présence d'un élément dans le code des pages est déconseillée
car couteuse en perfs (chaque page généré par spip doit être analysé
par la regex du pipeline).
