il me semble qu’il y a plusieurs besoins récurrents dans les plugins qui mériteraient d’être rendu possibles par simple déclaration dans le paquet.xml.
Je ne fais pas de proposition de syntaxe à ce stade.
- Marqueur de cache
Pouvoir déclarer que le plugin modifie le cache du site : le cache des pages n’est pas le même selon que le plugin est actif ou non.
C’est actuellement possible via $GLOBALS[‘marqueur’] mais ça oblige à faire un fichier _options.php juste pour ça, ce qui est contreproductif d’un point de vue perf
- Marqueur de compilation de squelette
Pouvoir déclarer que le plugin modifie le squelette compilé (parce qu’il propose des filtres spécifiques, surcharge, modifie certains filtres, fournit des balises…). Exemple typique des crayons : quand on les desactive cela fait planter des pages du site sauf à recalculer manuellement (ou vider le cache).
C’est actuellement possible via $GLOBALS[‘marqueur_skel’] mais ça oblige à faire un fichier _options.php juste pour ça, ce qui est contreproductif d’un point de vue perf
- Ajout d’une feuille de style CSS dans le <head>
Cette déclaration éviterait bien souvent de devoir implémenter le pipeline insert_head_css et d’écrire 5 lignes de codes qui reviennent tout le temps. Cela permet aussi une implémentation commune optimale du point de vue de l’insertion des CSS.
Il faut sans doute pouvoir spécifier le media en plus du nom du fichier.
- Ajout d’un JS dans le <head>
Cette déclaration éviterait bien souvent de devoir implémenter le pipeline insert_head et d’écrire 5 lignes de codes qui reviennent tout le temps. Cela permet aussi une implémentation commune optimale du point de vue de l’insertion des CSS.
Moi perso j’aimerais trouver un moyen générique pour insérer des scripts en fin de page sans passer par le pipeline affichage_final. J’aime mettre le minimum de scripts dans la partie et ne charger qu’en toute fin ceux qui n’agissent pas tout de suite (crayons, etc)
Encore une fois de plus, donc, mettre les scripts en bas de page n’est pas une pratique optimisée, et a surtout l’incroyable bénéfice de faire péter javascript dès qu’il y a un appel JS inline dans le corps de page inséré par un plugin.
Ce n’est donc pas une pratique généralisable pour laquelle on peut proposer un outil générique.
Dans le cas où, toi, tu aimes vraiment bien cette méthode, rien ne t’empêche de te faire un pipeline dédié #PIPELINE{js_foot}.
Utiliser un chargeur asynchrone JS que l’on insère dans le head est plus efficace que de mettre les scripts en bas de page.
On jour — de plus en plus proche — ce sera surement nativement proposé par un des plugins de SPIP.
il me semble qu’il y a plusieurs besoins récurrents dans les plugins qui mériteraient d’être rendu possibles par simple déclaration dans le paquet.xml.
Je ne fais pas de proposition de syntaxe à ce stade.
- Marqueur de cache
Pouvoir déclarer que le plugin modifie le cache du site : le cache des pages n’est pas le même selon que le plugin est actif ou non.
C’est actuellement possible via $GLOBALS[‘marqueur’] mais ça oblige à faire un fichier _options.php juste pour ça, ce qui est contreproductif d’un point de vue perf
- Marqueur de compilation de squelette
Pouvoir déclarer que le plugin modifie le squelette compilé (parce qu’il propose des filtres spécifiques, surcharge, modifie certains filtres, fournit des balises…). Exemple typique des crayons : quand on les desactive cela fait planter des pages du site sauf à recalculer manuellement (ou vider le cache).
C’est actuellement possible via $GLOBALS[‘marqueur_skel’] mais ça oblige à faire un fichier _options.php juste pour ça, ce qui est contreproductif d’un point de vue perf
Faire ça au niveau du fichier XML est insuffisant: lorsque le numéro de version du plugin change, les mêmes problèmes risque de se poser.
Perso, en SPIP2 j'ai dans mes_options.php:
La meta plugin_header contient tous les plugins avec leur version, donc dès qu'un plugin est mis à jour où disparait, ça invalide les caches des pages et des squelettes.
- Ajout d’une feuille de style CSS dans le <head>
Cette déclaration éviterait bien souvent de devoir implémenter le pipeline insert_head_css et d’écrire 5 lignes de codes qui reviennent tout le temps. Cela permet aussi une implémentation commune optimale du point de vue de l’insertion des CSS.
Il faut sans doute pouvoir spécifier le media en plus du nom du fichier.
- Ajout d’un JS dans le <head>
Cette déclaration éviterait bien souvent de devoir implémenter le pipeline insert_head et d’écrire 5 lignes de codes qui reviennent tout le temps. Cela permet aussi une implémentation commune optimale du point de vue de l’insertion des CSS.
Je n'utilise pas ces trucs là, mais en ce qui concerne la syntaxe du fichier XML, la solution la plus évidente à première vue est d'ajouter un attribut "type" à la balise pipeline, avec comme valeur possible "js" pour le 2e cas, "screen" "handheld" etc pour le 1er.
Euh je pige pas.
Si c'est des variables il est donc possible de modifier leur valeur.
Comment peux-tu te passer d'un CVT ?
Par contre, dans un vieux thread/article j'avais proposé de se rapprocher
de la déclaration des tables de la base. On pourrait même imaginer générer
le CVT à partir de cette description.
Si c'est des variables il est donc possible de modifier leur valeur.
Comment peux-tu te passer d'un CVT ?
Je pensais à un truc comme dans Firefox : les variables sont déclarées par
chaque plugin, avec leur type (de base), et le panneau de contrôle standard
qui permet de tout éditer.
ca rejoint en parti le débat qu'on avait avec b_b sur irc l'autre jour : faut-il avoir la possibilité désactiver certes elements de formulaire cfg si une variable globale / une constante est défini par l'utilisateur (afin de permettre de déploier facilement des plugins pré-configuré sur des sites)
Eric était pas pour, moi et b_b y étions favorable
Je reviens sur deux des propositions de Cédric pour voir si il est
possible de l'embarquer dans la 3.1 ou pas.
- Ajout d’une feuille de style CSS dans le <head>
Cette déclaration éviterait bien souvent de devoir implémenter le
pipeline insert_head_css et d’écrire 5 lignes de codes qui
reviennent tout le temps. Cela permet aussi une implémentation
commune optimale du point de vue de l’insertion des CSS.
Il faut sans doute pouvoir spécifier le media en plus du nom du fichier.
- Ajout d’un JS dans le <head>
Cette déclaration éviterait bien souvent de devoir implémenter le
pipeline insert_head et d’écrire 5 lignes de codes qui reviennent
tout le temps. Cela permet aussi une implémentation commune optimale
du point de vue de l’insertion des CSS.
Je vois deux possibilités pour inclure cela dans le paquet.xml:
- deux balises distinctes
- une baiise généraliste.
1) deux balises distinctes:
Dans ce cas on pourrait imaginer deux balises assez proches de leur
utilisation comme :
<style path="chemin/nom.css" type="public" media="screen" />
<script path="chemin/nom.js" type="prive" />
<script path="chemin/nom.js" />
Ces balises sont multiples.
Par cohérence avec l'attribut type de la balise <chemin> l'absence
d'attribut type signifie public et privé
Questions :
- le nom des balises convient-il ?
- est-ce bien un path que l'on veut et pas une url (sinon le nom de
l'attribut changera, cf la DTD) ?
Ah bonne remarque, ça peut être l'un ou l'autre : un path qui passe par find_in_path() pour faire une url relative, ou bien directement une URL (si on ajoute une librairie js ou css sur un CDN)
Est-ce qu'on peut avoir l'un ou l'autre attribut (et l'un des deux est obligatoire, les deux ensemble est interdit) ? Ou est-ce qu'on met un seul attribut et on traite de façon smart selon si il contient un path ou une url ?
2) Une seule balise unifiée
<inclure xxx="css" path="chemin/nom.css" type="public" media="screen" />
<inclure xxx="js" path="chemin/nom.css" />
Questions :
- les mêmes que pour le cas 1) : nom de la balise, path ou lien
- quel nom pour l'attribut css ou js sachant que type est déjà pris.
A la reflexion inclure n'est pas le bon terme, car on n'inclue rien, on ne fait que referencer/linker/declarer
A la rigueur <import...> pourrait convenir par analogie avec le @import css mais ça a moins de sens pour le js donc je sais pas...
Il faut aussi prevoir un xxx="text/css" ou xxx="text/javascript" car l'extension ne permet pas forcement de trancher (cas d'un skel utilisé par exemple)
C'est peut être mieux quand même d'avoir 2 balises distinctes pour les 2 usages...
Mais je pose une question sans y avoir réfléchi plus que ça : pour les css, est ce que ça vous parait utile d'envisager dès maintenant la possibilité d'appeler des css à "pré-processer" ?
C'est à dire pouvoir utiliser par exemple <style path="chemin/nom.css" preprocesseur="sass">, quite à nécessiter le plugin (less/sass) qui va bien.
Ça serait peut être utile pour le public, peut être moins pour le privé (quoique).
Il n'y a pas besoin de traiter ça au niveau du xml. On pourra y indiquer une feuille less ou sass à la place d'une css, le pre-processeur prend la main ensuite et choppe/compile les feuilles less/sass du head. Le core n'a pas besoin de savoir/connaitre ça.
J'avais pensé à <style path="chemin/nom.scss"> en premier lieu.
C'est vrai que si la css est appelée systématiquement avec un produire() ça devrait être suffisant.