Committo,Ergo:sum a écrit :
Je ne comprends pas pourquoi le pas du squlette n'a pas été franchi ici: en gros c'est
<BOUCLE1(OBJET){id_PRIMARY}>[(#champ1|si_actif('champ1'))] [(#champ2|si_actif('champ"))] ...
Evidemment c'est moins générique que la fonction actuelle, mais comme elles repose sur des autorisations qui elles-meme sont finies, cette généricité est illusoire (sauf si on s'autorise des bugs cf 10355 sur ce fichier). Y a-t-il vraiment des plugins qui l'utilse ?
Pas encore, mais l'idée est justement de gerer une liste non prédéfinie de champs afin de permettre aux plugins d'ajouter des champs aux objets spip et que ce soit supporté dans l'interface sans que le plugin n'ait de surcharge à faire (ie que deux plugins differents puissent ajouter des champs sur le meme objet sans probleme de cohabitation)
Quand je vois les usines a gaz qui ont commencé à être montées pour étendre par exemple les auteurs, je crois qu'il est grand temps de combler ce besoin.
Bien d'accord avec ce deuxième point mais pas avec le premier, car ça ne résoudra pas le problème de 2 plugins qui ont choisi le meme nom de champ à rajouter dans une même table.
Chaque plugin a un prefixe unique qui sert d'espace de nommage des fonctions, et qui devrait être utilisé de même pour les eventuels champs qu'ils ajouteraient aux tables
Alors plutot que d'inciter encore plus à poursuivre une fausse piste, je pense qu'il faut au contraire mettre un Hola. Les premières versions du compilateur ne savaient pas gérer un champ supplémentaire dans une table standard de SPIP, pour la bonne raison que ce n'est pas comme ça qu'on fait du développement collaboratif en SQL: si je veux ajouter des infos à une table sans préjuger d'autres infos amenées par d'autres, je crée une autre table avec une jointure sur la clé primaire de la première.
Oui enfin c'est assez différent. Et pour le coup ca alourdit justement le travail d'écriture des squelettes publics.
Typiquement si je veux ajouter des champs surtitre,soustitre,champo,descriptif,ps aux rubriques, il serait assez pénible de devoir doubler chaque boucle rubrique...
Il n'y a que ça qui tient la route, et ça permet aux auteurs de squelettes de pouvoir opérer, plutot que de réserver l'usage d'infos supplémentaires aux inventeurs d'usines à gaz en PHP. Il n'y a actuellemnent que 5 appels à cette fonction (dont 2 portent sur la meme table), je pense infiniment plus raisonnable de les remplacer par les squelettes sous-jacents pour couper court à des développements qui s'annuleront 2 à 2.
Dans un cas il y a un risque de conflit entre 2 qui utiliseraient le meme nom de champ (risque limité si on prend le soin de prefixé les champs supplémentaires), et dans l'autre cas, seul un plugin peut avoir la main pour ajouter ses propres champs.
Cette dernière solution n'est pas satsifaisante car ajouter des champs réponds à des besoins différents, et je vois mal devoir faire un plugin par objet qui agglomererait tous les ajouts possibles.
Tu avais dit une fois précédente,
'si plusieurs plugins veulent surcharger la meme fonction (ou squelette ici) alors c'est qu'on a un problème de conception'
On peut peut-être avoir un fonctionnement intermédiaire :
avoir un pipeline sur la liste des squelettes a evaluer pour afficher le rendu de l'objet.
Par defaut il n'y a que le squelette de base, et les plugins qui veulent ajouter des infos peuvent produire un squelette qui ne s'occupe que de leur morceau, et n'ont qu'a ajouter ce squelette à la liste, spip s'occupant de tout mettre bout a bout.
Cela permettrait
- la surcharge pour les cas simples ou ponctuels
- l'extension non conflictuelle, sans prejuger des choix d'implementation sql par les plugins
En plus, si on a la bonne idée de mettre l'id_rubrique dans le contexte, cela permettrait meme d'adapter le rendu dans certaines parties du site (et symétriquement le formulaire).
Ca te plairait plus comme cela ?
Cédric
