Paramètrage d'un champ extra déclaré dans un plugin

Bonjour, Est-il possible de "gérer" via l'interface de champs extra, des champs qui sont définis dans un plugin via l'API declarer_champs_extras ?

Même si c'est super de pouvoir déclarer ces champs à l'installation, il serait donc mon cas souhaitable, que l'on puisse affiner certains paramètre sans passer par les mises à jour du plugin.

Merci, Jul

added question label

il me semble que la question doit plus se poser dans champ extra interface. De memoire j'ai vu un truc pour gérer cela. Mais je suis plutot méfiant lorsqu'on melange de la config en code et de la config en interface graphique.

j'ai tendance à penser que si ton but c'est d'ajuster le champ extra d'un plugin, il vaut mieux le faire dans un sous plugin qui se branche sur le pipeline declarer_champ_extra. Je fais cela dans un squelette perso pour regrouper certains champs extra par catégorie.

Je comprends quand même le besoin, si par exemple tu veux un champ obligatoire, que tu ajoutes donc "en tant que dév", mais que par contre tu veux toujours permettre de personnaliser le label, l'explication, voir même encore plus la liste des choix (quand ya plusieurs choix possibles fermés).

Et ça dans une unique interface déjà connue et prévue, pas en plusieurs endroits différents (certains champs dans la page de CE Interface, et d'autres dans une autre page de config différente).

Il y aurait sûrement un truc à faire pour permettre ça dans le constructeur, mais le point d'attention à mon avis est sur les configs possibles :

• est-ce qu'on permet ça dans une config de CE Interface (autoriser à personnaliser les champs extras déjà définis)
• est-ce qu'on permet dans CE Core dans la déclaration de dire "je veux bloquer ce champ et ne jamais permettra sa personnalisation" (pris alors en compte dans CE Interface)
• une fois activé personnalisé sur un champ, que se passe-t-il si on supprime ou désinstalle la déclaration de départ avec CE Core : est-ce que ça supprime le champ quand même, ou ceux personnalisés restent toujours déclarés mais par CE Interface ?

etc etc, ça pose un certain nombre de questions

Dans mon cas de figure, effectivement le champ ne devrait pas être totalement manipulable (pas de suppression, pas de changement d'id, etc ...). Mais pouvoir modifier label, explication, valeur par défaut, les choix d'un select, vérification, obligation...) ce serait top.

ca rend hyper compliqué l'interface user et api :)...

(et quoi qu'il en soit, le ticket concernant champ extra interface, donc je déplace)

L'idée m'est venu en essayant d'utiliser "La Fabrique", vu que la déclaration des champs en PHP ne fonctionne pas trop pour le moment. Je me suis dit, que ce serait bien de déclarer tous mes champs via le plugin et de gérer les options de saisies via l'interface, ce serait tellement plus souple. Par exemple, sur mon nouveau plugin, il y a plein de select avec des datas qui peuvent changer quelques fois par an sans mériter pour autant d'avoir une table dédiée à chaque fois... Iextra permets également d'accéder à tellement d'option pratique.

Mais je comprends bien que cela rajoute un niveau de complexité.

Pour le coup de la liste de data que les utilisateurs peuvent changer, j'utilise des groupes de mots clés.
Mais c'est vrai qu'à force, sur un gros site, ça peut en faire beaucoup, qui se mélangent avec des groupes de mots clés fonctionnels, éditoriaux...
Peut être un plugin relativement générique et simple de gestion de référentiels serait utile ?

dans le cas de mon association, j'utilise une config. Avantage : c'est a part, donc on touche pas souvent. C?est géré avec d'autres elements de config. Et je regroupe les choses par onglets verticaux thematiques.

et aussi: c'est moins touffu comme interface qu'un champs extra interface.

et j'utilisa la même syntaxe que pour declarer des datas en formidable, donc iels connaissent

Je comprends bien qu'il y a des façons de contourner le problème des datas, mais il me semble qu'avoir accès à l'ensemble des options de saisies via une interface ce serait chouette quand même.

certes. Bah dans ce cas, propose l'ergonomie, puis code la PR correspondante :)

M'est-avis que l'ergonomie ne devrait pas trop changer, ce serait plus une amélioration coordonnées entre l'API de champs extras et le constructeur de formulaire.

• Dans Champs Extras interface, afficher aussi les champs déclarés par l'API, mais grisés disabled par défaut
• Sur l'API champ extra, pouvoir dire qu'on accepte qu'un champ précis soit éditable après coup (par défaut toutes les options du champ ?). Dans ce cas il n'est plus grisé dans le constructeur, et on peut l'éditer. Ces infos sont enregistrés en base, et surchargent celles venant du PHP pour celles qui sont définies.
• Permettre d'indiquer une liste autorisée et/ou liste interdite de quelles options éditables, dans ce cas ça fait la soustraction et ne garde que ce qu'il faut. Dans le constructeur, quand on édite le champ, ça ne montre que les options qu'on a le droit de modifier (ça ne met même pas les autres en grisés, on les affiche pas du tout). Quand on enregistre, seuls ces options autorisées surchargent celles du PHP, les autres restent pareils.
• Le top du top : permettre de surcharger la position du champ aussi (quand autorisé)

Je suis d'accord avec RastaPopoulos

Dans Champs Extras interface, afficher aussi les champs déclarés par l'API, mais grisés disabled par défaut

Ou on peut les lister comme pour les champs non-déclarés, avoir un bouton "Gérer ce champ"

Sur l'API champ extra, pouvoir dire qu'on accepte qu'un champ précis soit éditable après coup (par défaut toutes les options du champ ?). Dans ce cas il n'est plus grisé dans le constructeur, et on peut l'éditer. Ces infos sont enregistrés en base, et surchargent celles venant du PHP pour celles qui sont définies.

Permettre d'indiquer une liste autorisée et/ou liste interdite de quelles options éditables, dans ce cas ça fait la soustraction et ne garde que ce qu'il faut. Dans le constructeur, quand on édite le champ, ça ne montre que les options qu'on a le droit de modifier (ça ne met même pas les autres en grisés, on les affiche pas du tout). Quand on enregistre, seuls ces options autorisées surchargent celles du PHP, les autres restent pareils.

Oui, on peut se contenter d'interdire la suppression du champ (suppression du bouton) et la modification de la clé, ensuite je donnerais la main au webmestre de pouvoir changer les champs techniques et aux admins les champs d'interface (label, explication, data, defaut etc). Je peux préparer une liste exhaustive, le cas échéant les champs en question seraient désactivées.

moved from champs_extras_core#26 (déplacé)