Hello,
En travaillant sur les DTD plugin et paquet je me suis rendu compte des petits problèmes suivants autour du procure du core :
- Les DTD:
La DTD plugin indique une syntaxe : , version étant facultatif.
La DTD paquet indique une syntaxe : , compatibilite étant facultatif.
Etant donné que procure est une fonctionnalité SPIP 3 il n’y a aucune raison déjà d’avoir une différence.
D’ailleurs il serait bon de passer le plugin.xml du core en paquet.xml avant la sortie de la version finale.
- La version déclarée
Aujourd’hui pour itérateurs, le core déclare fournir la version 0.3.0.
Mais en fait ce n’est pas exact : le plugin Itérateurs est en 0.6.0 (et compatible SPIP 2.1 max) et le service identique du core a lui aussi subi les mêmes évolutions.
En outre, l’activation d’un plugin nécessitant itérateurs en version 0.3.5 est refusée alors qu’en fait le core procure bien les fonctions nécessaires.
Donc cela milite pour considérer la version comme une version minimale et donc l’écriture de la DTD paquet serait plus adaptée.
Mais si on ne ferme pas cet intervalle avec une version max, on ne saurait pas surcharger simplement le service du core par un plugin fournissant le même service.
Ou alors, cette notion de procure devrait s’appuyer sur un plugin qui plus qu’une extension, serait un module insécable de spip : c’est que désignerait la balise procure alorsdans ce cas ???
- SVP
SVP pour l’instant ne gère pas correctement les procure si on surcharge le service par un plugin fournissant ce même service.
Pour le corriger il faudrait donc définir un fonctionnement cohérent du core.
A votre avis ?
À mon avis le procure doit suivre exactement les mêmes contraintes que les déclarations de version (et non pas <necessite>, ce n'est pas une intervalle) et surtout les devs doivent suivre les mêmes contraintes lorsqu'ils modifient le code : le XML du core aurait dû être mis à jour en 0.6.0 si ya eu les mêmes évolutions fonctionnelles.
Ciao
A mon petit avis.
Procure devrait indiquer fournit au moins l'équivalent de la version x.y.z,
à SPIP de charger un plugin équivalent si celui possède une version de
valeur supérieure.
<procure id="iterateurs" version_mini="0.3.0" />
Km
Oui, mais alors il faut se rappeler *pourquoi* cette balise : le but était de dire que le noyau fournissait directement une fonction qui *avant* était en plugin, avec que les plugins qui les nécessitaient n'en ai plus besoin (bonux, jobs, wheel, etc).
Donc, si la fonctionnalité dans le noyau évolue et est plus avancée que celle d'un plugin, ya pas forcément intérêt à augmenter la version du <procure> car ce n'est pas une version à proprement parler. Ça signifie : le core procure la même fonctionnalité que le plugin AAA lorsqu'il était en version "x.y.z".
Soit un plugin AAA en version x1.y1.z1 fournissant un service.
La fonctionnalité est implémentée dans le core.
Le core <procure AAA en version x1.y1.z1>.
Le plugin AAA évolue en version x2.y2.z2.
Le core ne bouge pas, c'est toujours <procure AAA en version x1.y1.z1>.
Si c'est le core qui a changé mieux que le plugin, ça ne bouge pas *non plus*, car le but de la balise n'est *pas* d'indiquer l'état d'avancement de la fonctionnalité dans le core, mais d'aider les plugins qui nécessitaient un autre plugin à ne plus en avoir besoin.
En revanche, si le code évolue d'un côté *et* que c'est reporté de l'autre (peu importe le sens), comme l'exemple pour Itérateurs, alors là le <procure> doit être synchronisé avec la version du plugin.