[SPIP Zone] simplifier certaines taches des plugins

coucou,

si on fait le compte des plugins qui doivent insérer un css et un js,
ça fait pas mal, et la méthode (déclarer un pipeline, écrire une
fonction de manipulation du flux) est un peu lourde.

Je me demande si on ne gagnerait pas à standardiser ça en évitant de
déclarer une fonction, mais en intégrant simplement dans plugin.xml

<js>nom du fichier js</js>
<css>nom du fichier js</css>

en ajoutant même éventuellement des options (je pense par exemple à
<css public="oui"> pour ce qui va seulement dans le public, ou <js
footer="oui">...</js> pour les javascript qu'on peut déclarer dans le
footer) ?

et il y a ptete d'autres trucs simples mais répétitifs qu'on gagnerait
à standardiser de cette manière

-- Fil

oui tu as raison, ça pourrait couvrir pas mal de cas, mais il faudrait
prevoir aussi une condition sur une meta afin de rendre l'insertion
activable/desactivable sans avoir de code à écrire.

Cédric

Le 8 avril 2010 12:04, Fil <fil@rezo.net> a écrit :

coucou,

si on fait le compte des plugins qui doivent insérer un css et un js,
ça fait pas mal, et la méthode (déclarer un pipeline, écrire une
fonction de manipulation du flux) est un peu lourde.

Je me demande si on ne gagnerait pas à standardiser ça en évitant de
déclarer une fonction, mais en intégrant simplement dans plugin.xml

<js>nom du fichier js</js>
<css>nom du fichier js</css>

en ajoutant même éventuellement des options (je pense par exemple à
<css public="oui"> pour ce qui va seulement dans le public, ou <js
footer="oui">...</js> pour les javascript qu'on peut déclarer dans le
footer) ?

et il y a ptete d'autres trucs simples mais répétitifs qu'on gagnerait
à standardiser de cette manière

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

Le 8 avril 2010 12:19, Cédric Morin <cedric.morin@yterium.com> a écrit :

oui tu as raison, ça pourrait couvrir pas mal de cas, mais il faudrait
prevoir aussi une condition sur une meta afin de rendre l'insertion
activable/desactivable sans avoir de code à écrire.

Je crois que le travail sur petronille de Romy pose aussi le problème
de l'ordre de l'insertion de ces js/css dans la page... Comment gérer
ça ?

--
Bertrand

Le 8 avril 2010 12:04, Fil <fil@rezo.net> a écrit :

coucou,

si on fait le compte des plugins qui doivent insérer un css et un js,
ça fait pas mal, et la méthode (déclarer un pipeline, écrire une
fonction de manipulation du flux) est un peu lourde.

Je me demande si on ne gagnerait pas à standardiser ça en évitant de
déclarer une fonction, mais en intégrant simplement dans plugin.xml

<js>nom du fichier js</js>
<css>nom du fichier js</css>

en ajoutant même éventuellement des options (je pense par exemple à
<css public="oui"> pour ce qui va seulement dans le public, ou <js
footer="oui">...</js> pour les javascript qu'on peut déclarer dans le
footer) ?

et il y a ptete d'autres trucs simples mais répétitifs qu'on gagnerait
à standardiser de cette manière

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

Excellente idée. Du coup <css public="oui"> serait l'équivalent de
generer_url_public et permettrait d'utiliser des CSS squelettiques ?

A +

Luis

Le 08 avr. 2010 à 12:04, Fil a écrit :

coucou,

si on fait le compte des plugins qui doivent insérer un css et un js,
ça fait pas mal, et la méthode (déclarer un pipeline, écrire une
fonction de manipulation du flux) est un peu lourde.

Je me demande si on ne gagnerait pas à standardiser ça en évitant de
déclarer une fonction, mais en intégrant simplement dans plugin.xml

<js>nom du fichier js</js>
<css>nom du fichier js</css>

en ajoutant même éventuellement des options (je pense par exemple à
<css public="oui"> pour ce qui va seulement dans le public, ou <js
footer="oui">...</js> pour les javascript qu'on peut déclarer dans le
footer) ?

J'en profite pour signaler un besoin particulier des CSS, dont l'ordre d'appel des feuilles de style est particulier.

= Certaines (celles des plugins de reset, base et framework, comme BluePrint ou Pétronille) doivent être appelées *en premier* pour apporter leur bénéfice (sinon elles apportent tout le contraire : bien de la contrariété) et il n'y a pas moyen de faire cela actuellement.
(cf.: Connexion · GitLab )

Faut-il un <css public="oui" reset="oui"> ?

= Pour les autres, l'insertion devrait être *optionnelle*, ou du moins désactivable (ce qui peut se jouer ailleurs). A noter l'exemple du porte-plume dont la feuille de style, qui m'a donné récemment bien du fil à retordre, devrait être désactivable partiellement : sur le site public, mais pas dans l'espace privé.

= Pour les styles utilisateurs, il n'y a plus de problème dès lors que leurs feuilles sont appelées *après* les différentes insertions des plugins.

-- Romy

On 08/04/2010 12:04, Fil wrote:

coucou,

<js>nom du fichier js</js>
<css>nom du fichier js</css>

et il y a ptete d'autres trucs simples mais répétitifs qu'on gagnerait
à standardiser de cette manière

<autorisations>fichier_autorisations.php</autorisations> peut être...

C'est aussi le code d'install / désinstall / mise à jour des plugins qui pour la plupart pourrait certainement être simplifié aussi. On répète pratiquement tout le temps les mêmes actions :
- maj_tables() ou creer_base() à l'installation (+ pose de quelques index)
- sql_alter() sur les mises à jour
- drop_table ou sql_alter() sur la suppression.

Le code de «vider_table» est simple ça ne me gêne pas. C'est celui de upgrade qui je pense pourrait ptet être amélioré. Je sais pas trop encore comment, mais faire disparaître tout ce qui est enregistrement de la méta, pour le laisser gerer automatiquement par SPIP serait ptet une idée, peut être en spécialisant en 2 fonctions _install() et _upgrade()...

--
MM.

* Matthieu Marcillaud tapuscrivait, le 10/04/2010 18:27:

On 08/04/2010 12:04, Fil wrote:

coucou,

<js>nom du fichier js</js>
<css>nom du fichier js</css>

et il y a ptete d'autres trucs simples mais répétitifs qu'on gagnerait
à standardiser de cette manière

<autorisations>fichier_autorisations.php</autorisations> peut être...

C'est aussi le code d'install / désinstall / mise à jour des plugins qui
pour la plupart pourrait certainement être simplifié aussi. On répète
pratiquement tout le temps les mêmes actions :
- maj_tables() ou creer_base() à l'installation (+ pose de quelques index)
- sql_alter() sur les mises à jour
- drop_table ou sql_alter() sur la suppression.

Le code de «vider_table» est simple ça ne me gêne pas. C'est celui de
upgrade qui je pense pourrait ptet être amélioré. Je sais pas trop
encore comment, mais faire disparaître tout ce qui est enregistrement de
la méta, pour le laisser gerer automatiquement par SPIP serait ptet une
idée, peut être en spécialisant en 2 fonctions _install() et _upgrade()...

D'un autre côté, l'enregistrement de la meta de version, c'est une ligne que je garde en commentaires tant que je suis en phase de dev/test de la mise à jour, pour pouvoir rejouer la mise à jour facilement...

-- RealET

Le 08/04/2010 12:04, Fil a écrit :

et il y a ptete d'autres trucs simples mais répétitifs qu'on gagnerait
à standardiser de cette manière

Ni simple ni répétitif, et donc hors sujet,
mais qu'on gagnerait à rendre possible et facile
c'est la possibilité, non dans le plugin.xml mais dans un squelette ou sur un site,
de définir les endroits où le plugin est actif et là où il est inactif.

Car les plugins savent se rendent indispensables,
ils se multiplient au risque d'ambiguité et de ralentissements,
et pourtant, parfois, ils ne sont utiles que dans une rubrique, un secteur,
ou un squelette.

En passant,
JL

Le 17 avr. 2010 à 10:08, JLuc a écrit :

Le 08/04/2010 12:04, Fil a écrit :

et il y a ptete d'autres trucs simples mais répétitifs qu'on gagnerait
à standardiser de cette manière

Ni simple ni répétitif, et donc hors sujet,
mais qu'on gagnerait à rendre possible et facile
c'est la possibilité, non dans le plugin.xml mais dans un squelette ou sur un site,
de définir les endroits où le plugin est actif et là où il est inactif.

Car les plugins savent se rendent indispensables,
ils se multiplient au risque d'ambiguité et de ralentissements,
et pourtant, parfois, ils ne sont utiles que dans une rubrique, un secteur,
ou un squelette.

Typiquement la fausse bonne idée car cela obligerait à générer des contextes d'exécutions différents selon la rubrique ou autre, alors même que ce contexte n'est pas connu avant le chargement des plugins.
Usine à gaz à la clé (comme autrefois pour les invalidations de cache) avec un chute certaine des performances pour tout le monde et un gain hypothétique pour certains, dans certaines parties du site, ce qui reste encore à démontrer.

Cédric

2010/4/17 cedric.morin@yterium.com <cedric.morin@yterium.com>

Le 17 avr. 2010 à 10:08, JLuc a écrit :

Le 08/04/2010 12:04, Fil a écrit :

et il y a ptete d’autres trucs simples mais répétitifs qu’on gagnerait
à standardiser de cette manière

Ni simple ni répétitif, et donc hors sujet,
mais qu’on gagnerait à rendre possible et facile
c’est la possibilité, non dans le plugin.xml mais dans un squelette ou sur un site,
de définir les endroits où le plugin est actif et là où il est inactif.

Car les plugins savent se rendent indispensables,
ils se multiplient au risque d’ambiguité et de ralentissements,
et pourtant, parfois, ils ne sont utiles que dans une rubrique, un secteur,
ou un squelette.

Typiquement la fausse bonne idée car cela obligerait à générer des contextes d’exécutions différents selon la rubrique ou autre, alors même que ce contexte n’est pas connu avant le chargement des plugins.
Usine à gaz à la clé (comme autrefois pour les invalidations de cache) avec un chute certaine des performances pour tout le monde et un gain hypothétique pour certains, dans certaines parties du site, ce qui reste encore à démontrer.

Cédric

Je suis à 300% d’accord avec JLuc !
Et quand à le démontrer, ce serait d’autant plus facile avec un squelette à la Zpip.

Sur un site en cours, j’utilise jusqu’à 50 plugins (et pas que des légers…) + une demi douzaine de JQuery.

A terme, Il a fallu que je gère mes JQuery pour qu’ils ne s’activent que là où j’en avais vraiment besoin car sinon je me payais des charges de fou !
(j’ai créé un jeu de squelettes scripts/article.html scripts/rubrique.html etc… à la Zpip) Le gain de performance d’une page a l’autre s’est plutôt bien vu chez moi (en moyenne, une seconde et demi de moins pour les pages les plus lourdes et une baisse significative de l’ensemble si j’en juge par ma courbe Woozweb (monitoring en ligne))

Donc j’immagine le gain si on pouvait appliquer ce genre de traitement aux plugins et n’injecter leurs scriptouilles que là où elles servent vraiment. La page concernée serait peut être un peu lourde mais si ca peut fluidifier l’ensemble et le reste ca n’en serait que meilleur AMHA.

Parce que en plus, il faut quand même dire ce qui est, Insert_head fait des inclusions un peu anarchiques parfois quand tu utilises beaucoup de plugins (et oui, j’ai déjà évacué ceux qui n’étaient pas essentiels ou ne pouvait pas être remplacés par une simple ligne de code dans mes squelettes)

My 2 Cents…

Sinon pour l’idée de départ de Fil, je suis 100% pour aussi, surtout dans la mesure où ca permettrait à des gars comme moi de moins galérer à la création d’un plugin. :smiley:


Etienne Brackers.
http://www.loiseau2nuit.net/

L’oiseau2nuit a écrit :

Typiquement la fausse bonne idée car cela obligerait à générer des contextes d’exécutions différents selon la rubrique ou autre, alors même que ce contexte n’est pas connu avant le chargement des plugins.
Usine à gaz à la clé (comme autrefois pour les invalidations de cache) avec un chute certaine des performances pour tout le monde et un gain hypothétique pour certains, dans certaines parties du site, ce qui reste encore à démontrer.

Cédric

Je suis à 300% d’accord avec JLuc !
Et quand à le démontrer, ce serait d’autant plus facile avec un squelette à la Zpip.

Sur un site en cours, j’utilise jusqu’à 50 plugins (et pas que des légers…) + une demi douzaine de JQuery.

A terme, Il a fallu que je gère mes JQuery pour qu’ils ne s’activent que là où j’en avais vraiment besoin car sinon je me payais des charges de fou !
(j’ai créé un jeu de squelettes scripts/article.html scripts/rubrique.html etc… à la Zpip) Le gain de performance d’une page a l’autre s’est plutôt bien vu chez moi (en moyenne, une seconde et demi de moins pour les pages les plus lourdes et une baisse significative de l’ensemble si j’en juge par ma courbe Woozweb (monitoring en ligne))

Donc j’immagine le gain si on pouvait appliquer ce genre de traitement aux plugins et n’injecter leurs scriptouilles que là où elles servent vraiment. La page concernée serait peut être un peu lourde mais si ca peut fluidifier l’ensemble et le reste ca n’en serait que meilleur AMHA.

Parce que en plus, il faut quand même dire ce qui est, Insert_head fait des inclusions un peu anarchiques parfois quand tu utilises beaucoup de plugins (et oui, j’ai déjà évacué ceux qui n’étaient pas essentiels ou ne pouvait pas être remplacés par une simple ligne de code dans mes squelettes)

Pas d’accord à 300% (parce que d’accord avec Cédric sur la définition de contextes d’exécution, ça mer paraît ultra lourd), mais permettre un soupçon de filtrage sur INSERT_HEAD pour ne pas injecter les js et css de certains plugins dans certaines zones du site, oui.

a+
Simon

Le 19 avr. 2010 à 11:17, Simon Camerlo a écrit :

L’oiseau2nuit a écrit :

Typiquement la fausse bonne idée car cela obligerait à générer des contextes d’exécutions différents selon la rubrique ou autre, alors même que ce contexte n’est pas connu avant le chargement des plugins.
Usine à gaz à la clé (comme autrefois pour les invalidations de cache) avec un chute certaine des performances pour tout le monde et un gain hypothétique pour certains, dans certaines parties du site, ce qui reste encore à démontrer.

Cédric

Je suis à 300% d’accord avec JLuc !
Et quand à le démontrer, ce serait d’autant plus facile avec un squelette à la Zpip.

Sur un site en cours, j’utilise jusqu’à 50 plugins (et pas que des légers…) + une demi douzaine de JQuery.

A terme, Il a fallu que je gère mes JQuery pour qu’ils ne s’activent que là où j’en avais vraiment besoin car sinon je me payais des charges de fou !
(j’ai créé un jeu de squelettes scripts/article.html scripts/rubrique.html etc… à la Zpip) Le gain de performance d’une page a l’autre s’est plutôt bien vu chez moi (en moyenne, une seconde et demi de moins pour les pages les plus lourdes et une baisse significative de l’ensemble si j’en juge par ma courbe Woozweb (monitoring en ligne))

Il ne faut pas confondre activation d’un plugin et injection de css/js sur la page.
Autant l’activation d’un plugin par morceaux de site me parait fumeux, autant l’injection par les plugin de js et de css uniquement sur les pages qui en ont l’usage est souhaitable dans bien des cas.

Pour le moment on ne dispose pour cela que d’une solution qui est que le plugin passe dans le pipeline affichage_final et ne s’insère que si il trouve qu’on a besoin de lui.
Typiquement thickbox fait comme cela, et d’autres devraient en faire autant (comme le porte plume).
Si bien codé, la pénalité sur les pages n’utilisant pas le plugin est minime (un str_pos) et le gain important car cela evite effectivement des chargements inutiles.

Mais (he oui, il y a toujours un mais)

  • en s’insérant ainsi en fin de processus, les-dits plugins sont exclus du compactage. La page qui utilise le plugin sera donc plus longue à charger qu’avant (si on utilise le compacteur, évidemment)
  • il n’y a pas de mécanisme générique, c’est à chaque plugin d’être optimisé en fonction du ratio bénéfice/coût correspondant
  • on peut se poser la question de la multiplication des strpos en fin de hit et des insertions qui ne sont pas en cache dans ce cas.

Ce qui peut-être envisagé :

  • définir une API avec :

  • un « marqueur » de besoin (un tag html en commentaire qui peut être inséré souplement par une balise d’un plugin, ou une globale qui peut etre positionnée par un strpos)

  • un pipeline pre_affichage_final qui peut être utilisé pour la detection du besoin (ex presence d’une classe thickbox) pour les plugins qui le necessitent, qui leveront alors la globale de marqueur de besoin

  • deux squelettes insert_head_optionnel et insert_head_css_optionnel qui seront appelés par le core avec en contexte la liste des besoins levés par les marqueur html ou globale et qui provoqueront les inclusions de js/css necessaires pour la page considérée.

Ainsi :

  • pour une même liste de plugins necessaires sur une page, les ajouts de js et css seraient bien stockés en cache, et insérés en une unique fois là où c’est necessaire dans la page par SPIP
  • ces ajouts pourraient bénéficier du compacteur css et js

Je ne sais pas si au final ce serait beaucoup plus simple pour les plugins, et ça n’empêcherait pas d’avoir des plugins mal optimisés qui s’insèrent partout.

Cédric

2010/4/19 cedric.morin@yterium.com <cedric.morin@yterium.com>

Il ne faut pas confondre activation d’un plugin et injection de css/js sur la page.
Autant l’activation d’un plugin par morceaux de site me parait fumeux, autant l’injection par les plugin de js et de css uniquement sur les pages qui en ont l’usage est souhaitable dans bien des cas.

…/…

Ainsi :

  • pour une même liste de plugins necessaires sur une page, les ajouts de js et css seraient bien stockés en cache, et insérés en une unique fois là où c’est necessaire dans la page par SPIP
  • ces ajouts pourraient bénéficier du compacteur css et js

Je ne sais pas si au final ce serait beaucoup plus simple pour les plugins, et ça n’empêcherait pas d’avoir des plugins mal optimisés qui s’insèrent partout.

Cédric

J’ai pas tout compris mais je vois qu’on est d’accord :slight_smile:

Quand à la séparation du #INSERT_HEAD entre #INSERT_HEAD_OPTIONNEL et #INSERT_HEAD_CSS_OPTIONNEL ca fait des mois que j’en rêve. (dans mes neuronnes nébuleux je voyais plus un truc du genre #INSERT_CSS et #INSERT_JS mais Le côté optionnel tel que tu le présentes semble plus viable en effet,

(Si toutefois on peut en allant jusqu’au bout de la démarche, choisir que tel plugin n’inserera QUE ses CSS, tel autre, QUE ses js, tel autre encore rien du tout et tel autre encore, fera la total…

Quoi « c’est pas encore Noël » ? :-D)


Loiseau2nuit.
http://www.loiseau2nuit.net/

Le 19 avril 2010 19:42, L’oiseau2nuit <l.oiseau2nuit@gmail.com> a écrit :

J’ai pas tout compris mais je vois qu’on est d’accord :slight_smile:

Quand à la séparation du #INSERT_HEAD entre #INSERT_HEAD_OPTIONNEL et #INSERT_HEAD_CSS_OPTIONNEL ca fait des mois que j’en rêve. (dans mes neuronnes nébuleux je voyais plus un truc du genre #INSERT_CSS et #INSERT_JS mais Le côté optionnel tel que tu le présentes semble plus viable en effet,

(Si toutefois on peut en allant jusqu’au bout de la démarche, choisir que tel plugin n’inserera QUE ses CSS, tel autre, QUE ses js, tel autre encore rien du tout et tel autre encore, fera la total…

Quoi « c’est pas encore Noël » ? :-D)

Et un [(#INSERT_HEAD|exclus{barretypo}|exclus_js{couteausuisse})], ça serait pas plus simple à mettre en oeuvre ?
Au développeur de squelette d’identifier les zones à optimiser les les plugins à en exclure…

++
Simon

Le 19/04/2010 16:22, simon camerlo a écrit :

Et un [(#INSERT_HEAD|exclus{barretypo}|exclus_js{couteausuisse})], ça
serait pas plus simple à mettre en oeuvre ?
Au développeur de squelette d'identifier les zones à optimiser les les
plugins à en exclure...

Ben non. Parce que pour plein de gens, et encore plus depuis Zpip, la spécialisation ne fait plus jamais dans un squelette où il y a à la fois le head et le contenu de la page. Ça se fait via des plugins comme Compositions ou d'autres plugins qui utilisent le pipeline styliser (qui évite les article=5.html, etc).

Le #INSERT_HEAD il est là une fois pour toute, à un seul endroit, et je ne m'en occupe plus.

--
RastaPopoulos

Le 19 avril 2010 22:41, RastaPopoulos <rastapopoulos@spip.org> a écrit :

Le 19/04/2010 16:22, simon camerlo a écrit :

Et un [(#INSERT_HEAD|exclus{barretypo}|exclus_js{couteausuisse})], ça
serait pas plus simple à mettre en oeuvre ?
Au développeur de squelette d’identifier les zones à optimiser les les
plugins à en exclure…

Ben non. Parce que pour plein de gens, et encore plus depuis Zpip, la spécialisation ne fait plus jamais dans un squelette où il y a à la fois le head et le contenu de la page. Ça se fait via des plugins comme Compositions ou d’autres plugins qui utilisent le pipeline styliser (qui évite les article=5.html, etc).

Le #INSERT_HEAD il est là une fois pour toute, à un seul endroit, et je ne m’en occupe plus.

Le head peut recevoir l’env et à ce moment-là le développeur peut introduire des structures :

[(#ENV{id_mot} |?{ [(#INSERT_HEAD|exclus{barretypo}|exclus_js{couteausuisse})], #INSERT_HEAD })]

A ce sujet, et pour rejoindre un fil de discussion parallèle, un serait bien pratique :slight_smile:

A bientôt
Simon

Le 19/04/2010 15:49, simon camerlo a écrit :

Le head peut recevoir l'env et à ce moment-là le développeur peut
introduire des structures :

[(#ENV{id_mot} |?{
[(#INSERT_HEAD|exclus{barretypo}|exclus_js{couteausuisse})],
#INSERT_HEAD })]

A ce sujet, et pour rejoindre un fil de discussion parallèle, un
<switch> serait bien pratique :slight_smile:

A bientôt
    Simon

Si j'ai bien compris, dans ta proposition, c'est au niveau du squelette que tu gères tes exclusions.

Or, l'intérêt du #INSERT_HEAD c'était qu'un plugin puisse fournir des CSS et/ou JS sans que l'utilisateur du dit plugin n'ai besoin d'aller modifier son squelette.

Je vois pas l'intérêt de tester le besoin au niveau de l'inclusion #INSERT_HEAD dans le squelette car dans ce cas là autant supprimer la balise #INSERT_HEAD du squelette et inclure les CSS et JS des plugins à la main.

C'est au plugin qui injecte du code dans #INSERT_HEAD et non au squelette de spécifier quand est-ce que l'ajout d'une CSS ou d'un JS doit avoir lieu.

Pour ce que j'en ai compris

Cordialement

joseph

Le 19 avr. 2010 à 18:30, Joseph a écrit :

Le 19/04/2010 15:49, simon camerlo a écrit :

Le head peut recevoir l'env et à ce moment-là le développeur peut
introduire des structures :

[(#ENV{id_mot} |?{
[(#INSERT_HEAD|exclus{barretypo}|exclus_js{couteausuisse})],
#INSERT_HEAD })]

A ce sujet, et pour rejoindre un fil de discussion parallèle, un
<switch> serait bien pratique :slight_smile:

A bientôt
   Simon

Si j'ai bien compris, dans ta proposition, c'est au niveau du squelette que tu gères tes exclusions.

Or, l'intérêt du #INSERT_HEAD c'était qu'un plugin puisse fournir des CSS et/ou JS sans que l'utilisateur du dit plugin n'ai besoin d'aller modifier son squelette.

Je vois pas l'intérêt de tester le besoin au niveau de l'inclusion #INSERT_HEAD dans le squelette car dans ce cas là autant supprimer la balise #INSERT_HEAD du squelette et inclure les CSS et JS des plugins à la main.

C'est au plugin qui injecte du code dans #INSERT_HEAD et non au squelette de spécifier quand est-ce que l'ajout d'une CSS ou d'un JS doit avoir lieu.

Tout à fait. Ce n'est pas au webmestre de changer le squelette pour activer/désactiver le js/css de tel ou tel plugin sur telle page. Ça il est déjà possible de le faire en ne mettant pas #INSERT_HEAD et en ajoutant les css et js à la main en fonction des pages.

C'est au plugin de s'insérer intelligemment et en toute transparence sur les pages où il est nécessaire.

Cédric

Il arrive parfois qu'un développeur de site ait besoin d'une autre librairie que Jquery pour des utilisations particulières. Si JQuery entre en conflit avec cette application, c'est le bazar. Dans l'exemple cité, selon l'id_mot on met ou pas le #INSERT_HEAD. On pourrait penser que certains mots ont besoin de JQuery et d'autres d'une autre librairie. Je ne trouve pas l'idée complètement farfelue, je la trouve même très intéressante.

Bernard

cedric.morin@yterium.com a écrit :

Le 19 avr. 2010 à 18:30, Joseph a écrit :

Le 19/04/2010 15:49, simon camerlo a écrit :

Le head peut recevoir l'env et à ce moment-là le développeur peut
introduire des structures :

[(#ENV{id_mot} |?{
[(#INSERT_HEAD|exclus{barretypo}|exclus_js{couteausuisse})],
#INSERT_HEAD })]

A ce sujet, et pour rejoindre un fil de discussion parallèle, un
<switch> serait bien pratique :slight_smile:

A bientôt
   Simon

Si j'ai bien compris, dans ta proposition, c'est au niveau du squelette que tu gères tes exclusions.

Or, l'intérêt du #INSERT_HEAD c'était qu'un plugin puisse fournir des CSS et/ou JS sans que l'utilisateur du dit plugin n'ai besoin d'aller modifier son squelette.

Je vois pas l'intérêt de tester le besoin au niveau de l'inclusion #INSERT_HEAD dans le squelette car dans ce cas là autant supprimer la balise #INSERT_HEAD du squelette et inclure les CSS et JS des plugins à la main.

C'est au plugin qui injecte du code dans #INSERT_HEAD et non au squelette de spécifier quand est-ce que l'ajout d'une CSS ou d'un JS doit avoir lieu.
    
Tout à fait. Ce n'est pas au webmestre de changer le squelette pour activer/désactiver le js/css de tel ou tel plugin sur telle page. Ça il est déjà possible de le faire en ne mettant pas #INSERT_HEAD et en ajoutant les css et js à la main en fonction des pages.

C'est au plugin de s'insérer intelligemment et en toute transparence sur les pages où il est nécessaire.

Cédric
_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

--
Bernard Blazin - Développement Internet Ingénieur ENSAM promo 1978

Bernard Blazin Point Com

9 rue de la Rose
77320 Montolivet
Tel 01 64 20 98 49
http://www.bernardblazin.com

a écrit : Ok, vu comme ça en effet c’est beaucoup mieux si les plugins arrivent à gérer ça tous seuls. C’est juste que j’ai rencontré des cas où il aurait été beaucoup moins fastidieux d’exclure un .js parasite du insert_head sur certaines pages que de copier tout le bloc d’inclusions qui peut être assez gros d’une part, et qui demande de remettre à jour le squelette à chaque ajout / désactivation d’un autre plugin… A bientôt Simon