Le 15 mai 2010 à 11:59, cedric.morin@yterium.com a écrit :
passer par une fonction pour pouvoir spécifier la page de configuration me parait aller à l'encontre du but visé qui est de permettre de faire un plugin avec une page de configuration sans devoir (ni savoir) écrire de php.
Je suis aussi insatifait, mais j'étais perplexe devant l'avalanche de tests conditionant la configuration qui au final se résumait à: soit "?exec=cfg&fond=$PLUGIN" soit .... RIEN. Là au moins on a la possibilité d'aiguiller vers autre chose que CFG, ce qui était quand même une étape obligée vu le code complètement vissé à CFG qu'il y avait auparavant.
Il vaudrait mieux que <config></config> spécifie simplement le nom de la page de config (nom de l'exec), en le limitant de facto à un possible.
Bah non parce que ça veut dire écrire du PHP. Je pense que le but final est plutôt d'indiquer le formulaire CVT chargé de remplir les metas du plugin, qu'on pourrait même inclure en Ajax dans la page admin_plugin. Au passage je trouve qu'il y a des incohérences dans l'interface de programmation puisque certaines infos sont cherchées dans plugin.xml et d'autres sont écrites en dur dans le code (genre la fonction d'install == $nom_plugin . '_install'). Il faudrait être plus précis dans ce qu'on attend de plugin.xml.
Même si on pourrait accepter plusieurs <config>, ce raccourci ne saurait être qu'un raccourci vers une page accessible par ailleurs par le menu de configuration. Son existence est déjà en soi discutable, il serait de toute façon ergonomiquement aberrant de mettre là une pléthore de boutons de config.
Ben justement la fonction liste_onglet_cfg permet ça. Moi aussi je trouve ça aberrant, mais mon souci était de ne pas casser la compatibilité CFG, et d'offrir une migration facile vers les métas généralisées.
Je suis le premier à dire que CFG est un marteau-pilon pour écraser une mouche et qu'il faut le remplacer par qqch de beaucoup plus léger intégré au noyau, mais je rappelle tout de même qu'il s'agit de sortir la version 2.1.1, la version 2.1.0 étant par ma faute bancale sur ces histoires de MAJ de plugins via maj_while. Si on va plus loin maintenant, alors c'est vraiment une fonctionnalité nouvelle et on sort une 2.2. Là, je pense que c'est juste une échappée permettant à ceux qui savent coder en PHP d'expérimenter de nouveaux outils de configuration, en attendant de dégager des outils communs à mettre dans le noyau.
Si ça t'ennuie qu'il y ait une nouvelle entrée dans plugin.xml dont la signification risque de bouger, on peut la retirer et convenir de chercher la fonction $nom_plugin . '_config' (cf remarque ci-dessus), en attendant que les choses se clarifient.
Committo,Ergo:Sum