Après une discussion sur le déclaratif avec Fil, je me suis plongé dans le fichier de SPIP ecrire/core.xml qui est sensé déclarer les boutons, onglets, pipelines de SPIP à l’instar du fameux plugin.xml des plugins.
Cependant, toutes les balises de plugin.xml (ou de la nouvelle DTD paquet.dtd) ne sont pas encore utilisées et pourraient surement avoir un intérêt à l’être. Je pense à :
version, version_base et etat
nom, slogan (nouvelle DTD), description
licence, copyright (nouvelle DTD)
auteur, credits (nouvelle DTD)
lien (pour la doc, sera renommé en documentation dans la nouvelle DTD)
Après une discussion sur le déclaratif avec Fil, je me suis plongé dans le
fichier de SPIP ecrire/core.xml qui est sensé déclarer les boutons, onglets,
pipelines de SPIP à l'instar du fameux plugin.xml des plugins.
Cependant, toutes les balises de plugin.xml (ou de la nouvelle DTD
paquet.dtd) ne sont pas encore utilisées et pourraient surement avoir un
intérêt à l'être. Je pense à :
- version, version_base et etat
- nom, slogan (nouvelle DTD), description
- licence, copyright (nouvelle DTD)
- auteur, credits (nouvelle DTD)
- lien (pour la doc, sera renommé en documentation dans la nouvelle DTD)
- traduire
Ce serait pas mal.
Ma remarque portait sur les cron, qu'il faut déclarer dans un pipeline
qui appelle une fonction qui set une valeur en PHP... ce serait bcp
plus simple de les déclarer dans le XML <cron fréquence=xxx
fonction=xxxx>, au moins pour les cas simples. Le système ferait un
charger_fonction(xxxx, "genie/").
(je ne me fais toujours pas au mot "génie", d'ailleurs, car ça
m'évoque daemon, donc programme résident, et pas cron, programme lancé
périodiquement)
Mais ça m’a donné l’idée que l’on pourrait aussi le faire évoluer vers un plugin.xml de SPIP non ?
En particulier pour la balise traduire ça permettrait d’intégrer sans contournement les modules dans traductions.txt et je me demande si ça serait pas aussi intéressant pour les prochaines distributions.
Mais ça m'a donné l'idée que l'on pourrait aussi le faire évoluer vers un
plugin.xml de SPIP non ?
Oui ; le nom "plugin" fait bizarro, mais indépendamment de ça, au
moins faisons qu'on y récupère "traduire" et les balises qui font
sens.
Pour la notion de "distribution" aussi ça paraît clair. D'ailleurs,
est-ce que ça ne pourrait tout simplement pas se baser sur "necessite"
? Le zippeur prendrait le xml de la distrib, et irait chercher tous
ses paquets nécessités.
Oui ; le nom « plugin » fait bizarro, mais indépendamment de ça, au
moins faisons qu’on y récupère « traduire » et les balises qui font
sens.
Oui et même on peut garder core.xml.
Les balises qui me paraissent avoir un sens sont :
version, version_base et etat
nom, slogan (nouvelle DTD), description
licence, copyright (nouvelle DTD)
auteur, credits (nouvelle DTD)
lien (pour la doc, sera renommé en documentation dans la nouvelle DTD)
traduire
Pour la notion de « distribution » aussi ça paraît clair. D’ailleurs,
est-ce que ça ne pourrait tout simplement pas se baser sur « necessite »
? Le zippeur prendrait le xml de la distrib, et irait chercher tous
ses paquets nécessités.
Oui, ça pourrait le faire.
Et par contre, il faudrait juste prévoir :
de considérer ces necessite comme « non désactivables »
permettre de créer d’autres distrib eventuellement en surchargeant ce fichier core.xml par un distrib.xml si il existe. Enfin je sais pas trop
Pour moi core.xml c'est vraiment les déclarations *du core*. Pas de la distrib. Car le core lui-même a une version (juste celle du moteur) différente de la distrib. Pareil pour d'autres déclarations.
Donc d'après moi il vaut mieux un fichier *en plus* qui détermine spécifiquement la distribution. Celle par défaut aurait le nom de la distribution "SPIP", sa version propre, les extensions qu'elle nécessite, etc.
