[je passe sur spip-dev, ça dépasse spip-commit]
Moi je ne fais pas un spip sans bonux, alors que ce soit dans l'un ou l'autre je m'en fiche un peu.
Autrement dit tu te fiches de la cohérence du noyau; c'est tout de même un pb.
Non, mais j'ai compris depuis un moment que cette notion de cohérence et de périmètre du noyau est très variable selon qui l'aborde et je préfère consacrer mon énergie à autre chose que d'essayer de convaincre vainement qu'un certains nombres d'outils, filtres et balises sont plus que très utiles pour développer des squelettes et sites avec SPIP (même si on peut toujours faire sans ; d'ailleurs on peut aussi faire sans SPIP ...).
Donc j'utilise SPIP+bonux et je n'envisage même plus de raisonner sur SPIP seul.
Je ne crois pas être le seul à raisonner ainsi.
L'expérience montre que les fonctions automagiques qui essayent de faire plein de choses à la fois sont des fonctions compliquées, sources de bugs et d'effort de maintenance.
Si on parle d'expérience il faut justement se demander d'où sort ce bout de code.
Svn praise l'indique:
http://trac.rezo.net/trac/spip/changeset/11750
et le log dit que c'est probablement à cause de tout_paragrapher qu'il a fallu rajouter ce bout de code à une fonction qui était pratiquement identique à ton filtre lien_ou_expose au départ, mais dont tu vois qu'il n'est pas à l'abri d'une semblable mésaventure. Alors qui est-ce qui nie l'expérience ici ?
Ben justement, ce patch est mauvais. C'est à l'appelant d'appliquer |textebrut ou |PtoBR ou ce qu'il veut sur le contenu qu'il fournit comme titre du lien. Que ce soit dans les squelettes ou dans le php. C'est aussi beaucoup plus clair et lisible dans les squelette.
Puisqu'on parle des rapports entre noyau et plugin, il y a un autre point que je voulais aborder.
Une des fonctionnalités du plugin Association utilise le plugin Agenda. Je me souviens que tu as déploré sur spip-blog que personne n'y contribue,
que personne ne contribue à fournir des squelettes de présentation de l'agenda pour le public. De nombreux utilisateurs ont développés de tels squelettes pour leur site ou pour des squelettes génériques, mais personne ne s'est jamais donné la peine de mettre au propre et de rendre génériques de tels squelettes.
bonne nouvelle j'ai commencé à me pencher dessus.
L'un des messages sur cet article de spip-blog ici:
http://www.spip-blog.net/Contribuez-la-communaute-vous-le.html#forum2706
dit que rentrer dans le code c'est vraiment difficile.
J'ai donc été surpris de voir la nouvelle version d'Agenda requiert spip-bonux,
comme tous les plugins que je développe, cf plus haut.
ce qui gêne encore plus la compréhension du code, et pour quel gain ?
Mise en commun des outils...
Me semble-t-il, c'est seulement pour:
1. aoustrong, mais c'est un synonyme de lien_ou_expose qui est donc dans le noyau depuis un moment;
c'est l'ancêtre justement. Le plugin agenda a été l'occasion du dev de ce filtre, repris ensuite dans bonux, puis intégré dans le core sous un nom plus clair.
2. singulier_ou_pluriel, lui aussi dans le noyau maintenant;
idem, même histoire.
3. verifier_corriger_date_saisie, 1 occurrence pour compat d'avant usage spip-bonux, et 2 occurrences dans une fonction présente dans action/editer_evenement.php mais utilisée dans un autre fichier (pourquoi brouiller les pistes à plaisir ?), tout ce code n'étant pas très éloignée de ce qu'on trouve dans ecrire/inc/agenda et ecrire/action/editer_message.
c'est une fonction qui était à l'origine dans le plugin agenda, et qui a été déplacée dans bonux car utile à d'autres.
4. picker_selected, qui sert ici à associer un article à un événement, ce qui ne devrait pas être une obligation
c'est un avis. Mais le plugin agenda a pris le parti qu'un événement est obligatoirement associé à un article. La question s'est posée il y a 4 ans au début du développement du plugin et a été discutée collectivement :
- doit on faire d'un événement un objet éditorial autonome (avec ses auteurs, son statut de publication, et très rapidement son contenu éditorial),
- ou doit on choisir qu'un événement est un outil de datage des articles, et est obligatoirement associé à un article. Il peut alors avoir un contenu éditorial minimum, strictement lié à cette info de datage, et se passer d'auteur et de statut.
C'est ce dernier qui a été choisi. Rendre 'non obligatoire' l'association à un article poserait tout un tas de problème de gestion de la publication, et c'est quelque chose que je refuse de faire dans ce plugin.
comme le demande d'ailleurs qq dans le forum associé à ce plugin dans SPIP-Contrib
Que des utilisateurs demandent à pouvoir faire cela, c'est la nature des choses. Comme certains demandent à pouvoir mettre des brèves dans une sous rubrique, ou d'autres à pouvoir faire des boucles sur des tableau...
(qui est bourré de rapports de bug et de suggestions,
L'essentiel des rapports de bugs portent sur l'utilisation du calendrier-mini qui est pas simple à utiliser.
mais tu sembles avoir délaissé ce plugin et son forum depuis 2 mois au moins.
Répondre quotidiennement aux forums de 79 contributions est un boulot à plein temps que j'aimerais bien pouvoir faire. Mais comme il faut aussi remplir le frigo, il m'arrive d'être moins réactif par moment, j'avoue.
Cela dit, rassures toi, je vois bien passer et je lis tous les messages de forums tous les jours, et je réagis en général quand un bug est bloquant. Mais quand il s'agit du 250° message pour expliquer que le clic sur le calendrier mini ça va pas, je laisse les utilisateurs s'entre-aider, en effet.
Il faudrait aussi parler du code des fonctions inc/agenda_filtres qui forkent celui d'agenda_memo & Co, sans un commentaire expliquant pourquoi les originaux ne pouvaient pas être adaptés au besoin du plugin (mais sur ce point il semble que ce soit James qui soit à même de répondre).
Bref, l'arrivée des plugins était censée permettre la découpe sur mesure d'un SPIP personnalisé minimal pour chaque site, mais au final on se retrouve à devoir charger des usines à gaz doublonnant à 90%
Intégrons ce plugin dans le core alors, puisque 90% du code y est déjà...
ce qu'il y dans le noyau. Cette méthode de développemet n'est pas raisonnable.
Ah ben oui hein. C'est pas en s'opposant à l'intégration dans le core de fonctions dont *tu* n'as pas besoin que ça fait disparaitre le besoin des gens.
Donc on s'organise pour le satisfaire autrement. Et en pratique ça se traduit par un plugin bonux qui devient un spip++ et que à peu près tout le monde utilise.
Il est tout de même paradoxal que tu commences ce mail en ergotant sur la réelle utilité d'avoir intégré un filtre dans le core, et que tu le finisses en t'indignant qu'on fait plein de choses dans les plugins qui pourraient être fusionnées dans le core ...
Cédric
