...
J'ai l'impression en particulier que la question de tables de méta séparées est vue par toi comme un choix d'implémentation,
alors que pour moi c'est un choix de spécification,
...
Dans bien des cas (la plupart des cas ?) la configuration de la fonction n'a pas de sens en dehors du contexte où elle est faite, c'est à dire du site. Vouloir l'exporter indépendamment du reste des contenus parait incongru, et ne réponds absolument pas à un besoin.
On tourne au dialogue de sourds là-dessus car tu ne réponds pas à ce que j'ai déjà dit à ce sujet:
1. on peut convenir qu'on ne crée une table séparé que si plugin.xml le demande
oui, c'est une possibilité, mais la question est de savoir si cette information doit être rattaché au plugin.xml (comme dans ta proposition) ou au formulaire (comme dans CFG)
2. le surcoût supposé de tables meta systématiques ne serait-il pas un prix raisonnable à la simplification du code ?
Tu instruits le procès de ces tables uniquement à charge.
Non, non. Je t'assure que je n'instruis pas à charge, uniquement du point de vue de l'utilisateur de CFG et des CVT
On peut se poser la question des perfs du cache d'une seule table énorme qui doit être entièrement refaite dès qu'une seule meta change qq part.
Sur ce point, je suis bien d'accord.
Il y a quelques meta qui bougent "souvent", et on se retrouve à invalider complètement toutes les metas, alors qu'en effet, tout ce qui est lié à de la configuration ne bouge qu'à la demande d'un utilisateur. J'ai pu le voir en particulier avec le plugin job_queue qui note dans une meta la date du prochain job à effectuer, et qui change très souvent en présence de plugins utilisant la queue.
Mais la dichotomie core/plugin n'est pas forcèment pertinente dans ce cas, ce serait plutot une dichotomie "meta configuration"/"meta dynamique" à instaurer. Cela peut être traité par une table séparée par plugin, comme tu le proposes, mais aussi par un flag sur les metas, et un double cache, par une table "configuration" distincte de la table "meta" etc ...
Je note que l'on sort du débat, et que l'on aborde d'autres arguments qui n'étaient pas évoqués initialement et ne sont pas directement liés à notre question.
A ce compte là on pourrait aussi dire que les modèles sont des trucs trop petits qui ralentissent l'assemblage de la page. Pourtant on l'a fait parce que la fonctionnalité valait le coup. Je ne comprends pas la partialité dont tu fais preuve là-dessus, ainsi que d'autres sur cette liste qui affirment sans argumentation que ce serait "ingérable" alors que pour moi c'est la situation actuelle qui l'est (cf. le pb de dump de plugin dont je ne cesse de parler, et l'argument d'Eric sur la persistance des métas de plugins inactifs).
Moi je ne dis pas que c'est ingérable. Je dis juste qu'il faut que le passage d'un système (CFG) à celui que tu proposes se fasse sans écriture de php ; nombre de ceux qui utilisent CFG le font parce qu'ils ne savent pas coder en php.
Pour le moment je ne vois pas comment obtenir cela en suivant le chemin que tu proposes, mais je suis preneur de la démonstration inverse.
Dans la mesure du possible, il faut aussi éviter d'avoir à réécrire les squelettes qui utilisent les valeurs configurées, et cela nécessite aussi de prendre en charge #CONFIG{truc/chose} a minima.
Ce que je défends, c'est que proposer un système qui ne prend pas cela en compte c'est perdre son temps car les utilisateurs de CFG ne feront pas l'effort de migrer, et on ne résoudra pas la question. Aussi belle soit la construction.
CFG est conçu pour faciliter l'écriture rapide et facile d'un formulaire de configuration
...
Mais son périmètre fonctionnel est clair et bien défini.
Absolument pas.
si, si. Je t'assure. CFG sert à faire des formulaires de configuration. Il n'y est nul part question de plugin.
CFG se manifeste dans une page de l'espace privé qui s'appelle "admin_plugin", et il affiche un lien à côté d'un nom de plugin.
Ce n'est pas une fonction de CFG proprement dit, mais le core qui a pris cette liberté de proposer ce raccourci en s'appuyant sur CFG.
Si le développeur de SPIP que je suis en a conclu faussement que ça sert à configurer un plugin, alors que parait-il ça sert aussi à configurer d'autres choses, le webmestre moyen il va tomber dans le panneau à tous les coup. Je note d'ailleurs que je n'ai toujours pas les éclaircissements que j'ai demandés sur ces autres configurations ("une fonctionnalité" et "un squelette" as-tu écrit)
Très concrètement, j'écris un squelette dans mon dossier squelettes/ avec des paramètres configurables dedans (largeur maxi des images, affichage de tel bloc, nombre d'articles sur la page de sommaire ...) qui sont appelées par #CONFIG{truc/largeur_maxi}, #CONFIG{truc/afficher_bloc} #CONFIG{truc/accueil_nombre_articles} ...
Et mon squelette contient un formulaire de configuration basé sur CFG, dans lequel l'admin peut aller pour modifier le comportement de son site public.
Il n'y a aucun plugin dans l'affaire.
Son travail se limite au formulaire de configuration et uniquement ça. Il ne gère aucune notion de famille de formulaire ou de plugin etc ...
Mais c'est aussi ce qui permet de l'utiliser pour écrire un formulaire de configuration dans un squelette qui n'est pas un plugin.
Ce que je comprends à présent de l'USAGE qui est fait de cette usine à gaz, c'est que ça permet d'enregistrer qq part les saisies d'un formulaire, formulaire qui n'est pas forcément destiné à configurer qqch.
Si. Ça configure mon squelette dans le cas évoqué ci-dessus. Ce n'est pas un usage détourné de CFG, mais le coeur de ce pour quoi il a été fait et il est utilisé.
Si qq utilise une poële à frire comme si c'était un marteau c'est son droit, mais il n'a pas le droit de se plaindre que la nouvelle poële à frire qu'on lui propose enfonce moins bien les clous alors qu'elle cuit mieux et à moindre coût.
certes, mais alors il ne faudra pas s'étonner qu'il continue à utiliser la poële initiale qui continuera de fait à exister...
Je pense qu'on touche là le fond du débat et de notre différence de point de vue.
Tu fais l'hypothèse que si la construction est plus belle, les utilisateurs peuvent bien faire un effort pour migrer, alors que je pense que les utilisateurs ne migreront que si le service rendu est comparable, voire meilleur si il y a un effort de migration à faire de leur part.
Entendons nous bien, je ne nie pas certains intérêts de ce que tu proposes, mais je pense qu'en l'état ça ne changera nullement l'usage et l'utilisation de CFG parce qu'il y a plus d'inconvénient à migrer qu'à continuer à utiliser CFG. Et que du coup la cible est manquée de ce point de vue.
Ce que tu proposes couvre un périmètre différent, avec une autre approche et une autre spécification fonctionnelle.
Ce que je propose correspond à l'usage qui est suggéré par le nom "CFG" et la manière dont le noyau s'y interface.
Ben non, je ne vois nul part le terme 'plugin' dans 'CFG'... CFG permet de faire un formulaire de configuration.
Le fait de considérer qu'un formulaire de configuration est forcément dans un plugin est bien un usage différent.
Pour moi, rien que cette clarification est un progrès.
une évolution, en tout cas.
Dans ton code, il y a un bug très précis qui est que tu référence explicitement le nom du dossier dans lequel est rangé le plugin. Si chez moi je checkout tout le dossier Association, et que le plugin est donc dans plugins/Association/Association_2.0, cela ne marche pas (le squelette du formulaire n'est pas trouvé)
Un bug est un contradiction entre la spec et l'implémentation. Comme pour les tables, j'ai déjà dit que, si j'ai bien compris ce qu'est finalement la spec, il suffit d'enlever _DIR_plugin . $plugin dans le code. J'aimerais savoir si c'est suffisant où s'il y a encore un bout de spec que j'ignore.
il me semble, oui, que c'est suffisant sur ce point.
Ensuite, sur l'ambiguité dans l'utilisation d'un squelette par plusieurs balises, ça critique implicitement #ACTION_FORMULAIRE qui m'a toujours paru regrettable: c'est au compilateur d'insérer ce code, ce n'est pas à l'auteur du squelette d'utiliser cette incation magique à laquelle il ne comprend rien. Ajouté au fait que cette séquence de compil est bourrée de redondances (on teste la présence du squelette puis on appelle recuperer_fond qui refait un find_in_path via public_parametrer), on ferait bien mieux d'appeler directement le couple compilateur-cache sur ce squelette, enrichi dynamiquement du ACTION_FORMULAIRE sur les bons arguments (selon qu'on est en contexte CVT ou contexte Configurer).
On pourrait peut-être chercher à automatiser l'insertion de ces arguments ajoutés par la balise, avec les risque de complication quand un #FORMULAIRE_XX contient en fait des choses compliquées etc...
Mais je citais aussi le cas des pipelines, de la fonction charger() etc ... pour lesquelles on n'a pas, en l'état, une continuité de comportement entre les deux types d'appels d'un même squelette.
Pour le trio de fonctions CVT, de nouveau je rappelle que mon dernier envoi fournit une solution pour _verifier dont je redemande si la généralisation aux deux autres ne suffirait pas à résoudre le tout. Pour les pipelines je n'ai pas regardé. A noter aussi que les choses sont déjà un peu boiteuses autour de ce code car le charger_fonction pour X_verifier, X_charger et X_traiter ne va pas seulement tester l'existence de X_verifier.php mais aussi celle de X.php.
Oui, on peut ré-écrire tous les appels aux fonctions c,v,t et aux pipelines correspondants pour tacher de retomber sur nos pieds. Au prix d'une redondance de code et des appels, qui découle logiquement de la redondance entre #FORMULAIRE_CONFIGURER_PLUGIN{xx,truc} et #FORMULAIRE_CONFIGURER_TRUC
Mais on retombe je crois sur la question du départ. Le formulaire de configuration doit il être forcément lié à un plugin ou non.
Cédric
