Je vais envoyer cela dans spip_bonux, comme tous les trucs biens qui ne doivent pas être dans le core.
Les utilisateurs trancheront.
Autrement dit "je travaille à un produit spécifique en dehors de la référence commune et j'invoque les mannes de la concurrence libre et non faussée".
Il y a mieux comme apologie du travail collaboratif. J'ai peine à croire que c'est toi qui a écrit ça.
comment dois-je lire
http://trac.rezo.net/trac/spip/browser/branches/spip-2.1/ecrire/balise/formulaire_configurer_plugin.php#L36
qui référence le chemin direct vers le formulaire, avec en prime le bug de confondre prefixe du plugin et nom du dossier dans lequel il est rangé dans plugins/ ?
tu dois le lire sans abandonner des facultés de jugement qui sont visiblement parties en week-end avant toi:
ce code a été testé sur le plugin Association_2.0 dont le préfixe est "association",
si un tel bug existait je l'aurais vu.
J'ai pris le temps de lire le code,
Bien mal visiblement; alors reprenons calmement. Pour moi le développement collaboratif ça consiste à essayer de comprendre ce qu'ont fait les autres,
et quand j'en perçois des faiblesses j'essaye de comprendre si c'est intrinsèque à la méthode utilisée ou pas. Qu'il y ait des limitations au 5k de code PHP que j'ai envoyés par rapport au 200K de CFG, c'est probable mais la question est de savoir si c'est rédhibitoire ou pas.
Je passe en revue ce que tu dis d'un point de vue technique, pas du point de vue d'a prioris contestables.
Un formulaire forme une entité logique et automone dans CFG, indépendante du plugin auquel il est rattaché (ou non). Le stockage est associé au formulaire, pas au plugin.
Si l'idée est que les saisies de chaque formulaire doivent être regroupées en une seule entrée sérialisée, c'est facile à faire.
Faut seulement m'expliquer si c'est bien ça l'idée et si elle est vraiment bonne.
on peut faire encore plus petit, plus conforme et plus générique, en se passant d'introduire une nouvelle balise/syntaxe.
On se comprendrait déjà beaucoup mieux si tu arrêtais de confondre systématiquement vocabulaire et grammaire. Apprendre un mot nouveau c'est peu de chose, apprendre une nouvelle règle de grammaire ça demande beaucoup plus d'efforts de compréhension et de mémoire. L'idée du langage de squelettes c'est de définir une syntaxe (autrement dit un grammaire) une fois pour toutes, et d'introduire des mots nouveaux en fonction des besoins. Ca garantit un apprentissage minimal, surtout pour les nouveaux arrivants qui découvrent une langage dont le vocabulaire n'a cessé de s'enrichir au cours des années. Toi qui est là depuis des années, tu ne penses jamais à ça, et c'est, au fond, le seul reproche que j'ai à te faire.
A condition que mon formulaire soit dans un plugin.
Il m'avait semblé que c'était un apriori de CFG, aussi ai-je ajouté _DIR_PLUGINS dans le chemin par souci d'efficacité. Si ce n'est pas le cas, il suffit de l'enlever, pas de quoi hurler.
Vu des N>>1 plugins qui stockent 2 ou 3 valeurs de config, est-il sérieux de créer autant de tables que cela ?
Si tu y tiens absolument, on peut convenir qu'un plugin n'a une table des metas séparée que s'il y a une entrée "meta" dans plugin.xml qui en donne le nom. De nouveau pas de quoi hurler.
Je trouve significatif que tu prennes autant la mouche sur un tel non problème, car ça illustre bien une divergence de fond: pour moi, dès qu'un logiciel atteint une certaine taille, les économies de bouts de chandelle doivent être bannies, parce que le gain en place ou temps est négligeable face à la question de la lisibilité du code (pour la maintenance, pour les nouveaux arrivants etc). Et même au niveau perf, je suis bien certain que le temps de chargement du mastodonte CFG est sans commune mesure avec la lecture des caches de mini-tables metas.
Ce qui me fait voir rouge c'est que le même formulaire de configuration va devoir être appelé par #FORMULAIRE_CONFIGURER_PLUGIN{machin,truc}, puis si on veut implémenter un charger() spécifique car la regexp ne fonctionne pas, devient tout d'un coup #FORMULAIRE_CONFIGURER_TRUC. Et là, le traiter() par défaut n'est plus pris en compte, donc il faut le ré-écrire aussi.
Ce que j'ai posté pour _verifier tout à l'heure peut être fait pour _charger et _traiter si c'est ça le besoin. De nouveau pas de quoi hurler.
Par ailleurs tu ne t'es pas expliqué sur les 3 locutions employées dans tes mails: "configurer une fonctionnalité", "configurer un plugin" et "configurer un squelette", distinctions dont l'appellation éveille mon intérêt mais dont je n'ai pas l'impression que tu en es toi-même une vue bien précise. Ce que je propose à la base, ce sont des fonctions charger/verifier/traiter qui permettent de gérer des saisies d'un formulaire dans une table de meta (actuellement spécifique au plugin d'où provient le formulaire, mais je répète que la table std est utilisable). Ces fonctions sont activables via une balise proche de "#FORMULAIRE_", qui s'en distingue en ayant un trio de fonctions prédéfinies (alors que FORMULAIRE_ n'en a pas) et en précisant le chemin d'accès au squelette (c'est donc peut-etre un mauvais choix, mais ça saute facilement). En utilisant plusieurs fois cette balise dans un squelette, on peut proposer une page de "configuration de fonctionnalité", en ce que cette page alimenterait en une seule soumission des tables de métas issues de plusieurs plugins dont la réunion offre une fonctionnalité. Sauf erreur, CFG ne permet pas actuellement de construire une page multi-plugin, cela me parait donc une avancée.
Donc s'il te plait, essaye de retrouver tes facultés de jugements pendant le week-end et discutons calmement. Je rappelle que tout est parti de ma reprise du plugin Association que j'essaye de débarasser de CFG en touchant le moins possible au code du config du plugin, ce qui tend à prouver que c'est un travail utile à tous les utilisateurs de CFG et non, comme tu m'en accuses, d'un besoin perso qui ignore ce qui s'est fait autour de CFG depuis qu'il existe.
Committo,Ergo:Sum