Le 22 avril 2010 19:14, cedric.morin@yterium.com <cedric.morin@yterium.com> a écrit :
Le 22 avr. 2010 à 20:14, Joseph a écrit :
Le 22/04/2010 18:03, Bruno Bergot a écrit :
Salut Joseph,
Pourquoi pas un simple necessite du plugin original ?
http://zone.spip.org/trac/spip-zone/log/plugins/titre_parent
++
b_b
En l’occurence, ce plugin ne fournit qu’une balise et un filtre.
Du coup, je me demande s’il est vraiment nécessaire de rajouter encore une dépendance au squelette et donc encore un plugin à devoir installer pour l’utiliser.
Quand on en arrive à coder pour la 3ème fois (dans 3 plugins différents) la même fonction, c’est qu’il y a un problème.
Surtout que le core permet maintenant de faire ça nativement et plus génériquement avec
#INFO_TITRE{rubrique,#ID_RUBRIQUE}
On en découvre tous les jours. Merci pour l’info. Donc effectivement #TITRE_PARENT devient inutile.
Ceci dit, je me demande toujours s’il est pertinent d’avoir un plugin pour seulement un filtre ou un critère. Certes STEP permettra une fois fini de gérer les dépendances et on peut espérer qu’un jour ce plugin ou un équivalent sera livré comme extension pour les distributions standard de SPIP mais ce n’est pas encore le cas.
De fait, un plugin bibliothèque de filtres et de critères (basés sur les objets standards de SPIP, je ne parle pas de ceux qui sont liés à des objets propres à un plugin ou à ceux qui étendent les raccourcis typographiques) est utile. C’est donc ce que semble être Bonux.
D’autres contributions sont intégrées (il s’agit de filtre ou de critère, voir http://www.spip-contrib.net/ecrire/?exec=articles&id_article=3466) et pour elles la question ne se pose pas puisqu’elles ne sont pas distribuées sous formes de plugin.
En fait, ça pose le problème plus général de savoir si on fait un plugin juste pour un filtre ou un critère ou si ces derniers sont inclus dans un seul plugin.
C’était l’idée initiale du couteau suisse si je ne me trompe mais maintenant le CS est devenu une grosse machinerie un peu fourre-tout.
A qui le dis tu …
Mais il parait que c’est de la mauvaise foi que de dire cela.
C’est également ce qui me pose problème avec le couteau suisse. Il y a de tout là dedans sans compter que les lames sont activables/désactivables par l’utilisateur et donc que je ne me vois pas faire un squelette distribuable nécessitant le CS.
Certains critères filtres et balises sont fournis dans Bonux. La question est de savoir qu’est ce qui doit être ajouté à Bonux ou non.
Ce qui est récurrent et utile aux développeurs de plugins, mais sans interface.
Ce n’est qu’une grosse librairie de fonctions étendues.
Cédric
Si je puis me permettre, le petit hic qui m’avais gêné initialement avec Bonux c’est qu’il mélangeait à la fois une modification de l’espace privé (changement des CSS) et une bibliothèques de boucles, filtres et critères. De fait, pas possible d’avoir la bibliothèque sans la modification de l’interface. Pour moi cela aura du être deux plugins (sans vouloir troller).
Ensuite, la question est peut être de définir ce qui est considéré comme récurrent et utile aux développeurs de plugins (et je dirais aussi de squelettes ce qui peut être un poil différent).
Par exemple, actuellement sur Aveline, je me rends compte que le critère archives extrait du projet spip-clear, le filtre statistiques_mot et le critère compteur_publie original (car j’arrive pas à reproduire son comportement avec le critère compteur de Bonux) sont bien pratiques. Dès lors, il y a 4 possibilités :
1/ On considère que c’est un besoin récurrent (comment je sais pas) et ça va dans Bonux.
2/ On fait trois plugins spécifiques et on augmente le nombre de dépendances d’un squelette.
3/ On envisage à côté de Bonux une bibliothèque de filtres/balises/critères dont les besoins sont moins récurrents et qu’on regroupe ensemble. Une sorte de Bonus-Bonux pour ne pas les imposer à ceux qui n’ont besoin que d’un Bonux de base
4/ Ces contributions sont incluses par les squelettes qui les utilisent mais alors effectivement on duplique du code et j’ai bien compris que c’était mal.
Personnellement, je préfère la solution 1 ou la solution 3. Mais je ne sais pas ce qu’en pense les autres.
Joseph
