Re: Catégorie de plugins, SVP, SPIP et Composer

Re,

Le ven. 17 mai 2019 à 13:17, nicod_ <[email protected]> a écrit :

> Le 17/05/2019 à 10:53, Eric Lupinacci a écrit :
> > Yop,
> >
> > Le ven. 17 mai 2019 à 10:44, Maïeul <[email protected]
> > <mailto:[email protected]>> a écrit :
> >
> >
> >     autre piste : est-ce que la liste de catégories ne pourrait pas être
> >     servi à SPIP par un serveur externe (genre : le référentiel de
> plugin).
> >     Comme cela en cas de changement de liste, l'actualisation se fait
> plus
> >     simplement.
>
> C'est à quelque chose comme ça que je pensais, plutôt qu'une liste
> fournie en dur par SPIP ou un des ses plugins dist (ce qui reviendrait
> au même).
>

Oui on peut le voir comme ça.
Je m'interroge juste sur l'intérêt du truc.


>
> > Je ne suis pas sur que la récurrence des changements soit telle qu'il
> > faille imaginer autre chose qu'une release SPIP.
> > Le problème à mon avis le plus aigu restera la mise à jour des plugins
> > (paquet.xml).
>
> Je ne pensais pas du tout à un changement aussi radical que l'actuel,
> mais plutôt à des modifications au fil de l'eau et de l'utilisation, un
> ajout, un renommage...
>
>
Oui mais finalement un ou 1000 c'est un peu pareil.
La question est toujours : je migre (donc bing-bang) ou j'assure une
retro-compat.
Ca reviendrait à versionner les catégories en rapport avec SPIP....


> Question complémentaire : admettons que SPIP X dispose d'une liste de
> catégories, et que la nouvelle version SPIP Y en a une nouvelle.
> Est ce qu'un plugin qui utiliserait une de ces nouvelles catégories
> pourrait être "découvrable" et installé sur SPIP X ?
> Est ce qu'il y aurait d'autres effets de bord de ce type ?
>
>
En fait, il n'y a aujourd'hui (faudra que je vérifie quand même) pour moi
qu'un fil à la patte entre SPIP et les catégories.
C'est la validation du paquet.xml.
La DTD impose une liste :
<!ENTITY % CATEGORY
"auteur|communication|date|divers|edition|maintenance|multimedia|navigation|outil|performance|squelette|statistique|theme)"
>
Si on fait sauter cette contrainte, en conservant le caractère obligatoire
de l'attribut, en remplaçant cette liste par une simple chaine je pense
qu'on simplifie le problème.

Ensuite, la recherche elle n'est pas forcément contrainte par la catégorie.
Je pense qu'il faudrait faire une version n+1 pour chaque branche SPIP 3.x
en virant le critère catégorie de la recherche.
Je suis persuadé d'ailleurs que les critères de ce formulaire sont rarement
modifiés.

Après, je réfléchis en écrivant, mais si on voulait être hyper souple, la
seule solution serait de sortir la catégorie du XML et de compiler quelque
part (surement au niveau du référentiel des plugins) à la fois la liste des
catégories et les affectations.
Finalement ça revient à tenir à jour l'équivalent du fichier excel que
j'utilise pour revoir les affectations actuelles.
On peut imaginer une API REST pour lire cette liste et compléter la table
plugins en fin de traitement SVP.
Cela a aussi l'avantage de ne plus avoir à modifier les plugins lors de
migration de catégories voire de pouvoir versionner les affectations de
branche SPIP en branche SPIP.
Je me demande si ce n'est pas LA solution ?

++
Eric