Intégrer le plugin dans le noizetier
Puisque c'était le but. À discuter ici maintenant ce qui manque ou pas pour le faire.
Le 18/02/2019 à 14:01, @Eric a écrit :
Hello,
Je continue mon petit chemin sur tes nouvelles fonctionnalités. Si je comprends bien, noizetier_extra c'est le plugin qui permet "transformer" un input libre en sélection parmi une liste (ou un changer une liste de valeurs par une autre) mais j'en suis pas sur. En fait tu rajoutes un pipeline qui pourrait être directement appelé dans le formulaire editer_noisette si je comprends bien.
Pourrais-tu me donner un exemple de tableau retourné par ce pipeline stp ?
Le lun. 18 févr. 2019 à 14:19, @tcharlss a écrit :
Oui c'est l'idée.
Il y a un pipeline « noizetier_lister_saisies_classes » qui permet aux plugins de thèmes de déclarer des saisies pour les classes par type de noisette. Ça peut être des selects ou des checkbox : n'importe quelle saisie avec des valeurs prédéfinies. Il peut aussi y avoir plusieurs saisies si besoin. L'input de base est toujours là (il peut toujours servir si besoin).
Le 19/02/2019 à 09:27, @Eric a écrit :
Bon alors j'ai essayé cette fonctionnalité avec mon plugin zgala. Alors voilà mes remarques:
Cette fonctionnalité finalement permet soit d'écraser (ça j'en suis pas sur) soit de rajouter des saisies en PHP donc cela veut dire que ça ne permet que de modifier la saisies des *paramètres *de la noisette, c'est à dire que les attributs de la capsule ne sont pas concernés et pour cause ils sont ajoutés dans le formulaire via des saisies HTML. Est-ce voulu ou pas parce que je vois qu'à un moment tu vas chercher la valeur de "css" ? En tout cas j'ai essayé de mettre une sélection à l'attribut "css" de la capsule et là bien entendu je me suis retrouvé avec 2 fois l'input, une fois dans la partie de la noisette et une fois dans la partie encapsulation. Il me semble qu'il faudrait savoir si on s'autorise aussi d'atteindre les paramètres d'encapsulation ou pas et si oui, il faut changer le code plus profondément.
Dans les libellés et autres tu parles toujours de "classe" et donc que les saisies ajoutées concernent uniquement des paramètres portant une sémantique de classe. Le souci c'est qu'à aucun moment on exclut le fait de le faire sur d'autres champs qui ne portent pas cette sémantique. Dès lors faut-il garder cette pseudo-limitation sur les classes ou alors étendre le pipeline en disant que l'on peut modifier les saisies et donc la liste des paramètres d'un type de noisette tout bonnement (pipeline noizetier_type_noisette_saisies) ?
Les saisies se présentent comme une liste indexée de façon numérique. De fait, si on fait un merge de deux liste de saisies on n'écrase jamais rien, on ne fait que rajouter dans l'ordre des index. Je serais d'avis de modifier ce comportement de façon à "reconnaître" une saisie ("nom") et à merger les deux contenus, celui de base avec celui du pipeline. Ainsi, on ne serait pas obligé de redéfinir le label, l'explication... quand on ne veut finalement que changer le type d'input et/ou la liste des valeurs possibles.
Suivant ce que l'on décide au 1) on peut se poser la question de l'intérêt des saisies "*" valables pour tous les types de noisettes. Ca veut dire un paramètre général comme l'encapsulation, les css : est-ce vraiment un cas réel ?
De tout ça je dirais qu'il n'y a pas de contrainte à insérer cette fonction dans le noiZetier sauf a bien détourer la sémantique de la fonction. De mes points je dirais que la fonction permet une extension des paramètres propres à un type de noisette sans modifier le YAML et en modifiant ou pas (quand cela consiste juste à donner une liste de valeurs à un champ) le HTML. Est-ce bien ça ?
Le 19/02/2019 à 16:04, @tcharlss a écrit :
on, et comme tu le montres dans les points 1), 2) et 3), je suis moins convaincu par cette implémentation : ça peut poser des problèmes si on écrase des saisies existantes, et c'est un peu fastidieux de déclarer des saisies.
Finalement je pense qu'il faudrait revenir à un truc plus simple : pour chaque type de noisette, déclarer juste des listes de classes, en indiquant si chaque liste est multiple ou unique. Et à partir de ces informations, c'est le noizetier qui construirait les saisies appropriées (en évitant d'écraser des saisies existantes) : soit des select/radios, soit des checkbox.
Du coup pour les plugins utilisateurs, le pipeline pourrait ressembler à ça :
$classes = array( 'type_noisette' => array( 'type' => 'unique', 'classes' => array( 'variante-a', 'variante-b' ), 'type' => 'multiple', 'classes' => array( 'lorem', 'ipsum' ), ), );
Le cas '*' est nécessaire oui, on l'utilise en prod.
Voilà, après, le principe reste super simple : tout ce que ça fait, c'est d'ajouter les valeurs sélectionnées au champ 'css' ou 'conteneur_css' lors de la vérification, à coup de set_request. Donc pas besoin de toucher à l'encapsulation ou quoi que ce soit. Je pense qu'il faut conserver l'input pour saisir des classes libres au cas-où, les gens peuvent avoir leurs styles persos qui complètent le thème.
D'ailleurs, en parlant de ça, je suis de plus en plus convaincu que l'encapsulation est tout le temps nécessaire, et ne devrait être désactivable que dans de rares cas bien précis (et donc pas une option visible par défaut).
Le 20/02/2019 à 10:49, @Eric a écrit :
Ben en fait j'étais en train de creuser le plugin et j'avais fait un essai qui a priori n'était pas dans l'objectif prévu. Et je viens de comprendre véritablement en lisant la fonction vérifier.
Donc en fait dans votre vision, on RAJOUTE toujours des saisies de "type classe" sous une forme de liste (au sens large) et dont le résultat va toujours enrichir les champs css et conteneur_css qui d'ailleurs peuvent être aussi remplis avec l'input standard. Je trouve ça à la fois intéressant et un peu tordu pour plusieurs raisons:
- on va avoir deux ou plus d'inputs qui vont in fine construire un seul champ et l'ordre des saisies fait que l'input standard se retrouve en premier suivi des classes complémentaires ce qui est logique pour conteneur_css qui est un paramètre du type de noisette et moins pour css qui est un paramètre de la capsule.
- l'ordre dans le formulaire est ok pour conteneur_css et moins clair pour css car l'input css ne fait pas pas partie des saisies PHP et est inclus à la leur suite en HTML. Donc le fait de saisir avant des classes dans un fieldset différent est un peu bizarre.
- donc on ne peut pas remplacer l'input standard par une liste par exemple ce qui pourrait être intéressant. C'est d'ailleurs comme ça que j'avais fait mon test et je me suis retrouvé avec un input css dans la partie noisette et l'input standard dans la partie encapsulation.
Sans visu c'est peut-être pas très clair mon blabla :p.
En conclusion, je m'attendais à un mécanisme plus générique (j'ajoute ou je remplace des saisies de paramètres de la noisette ou de la capsule) et aussi plus spécifique dans la cible, à savoir, avec la possibilité de désigner à quel paramètre du type de noisette ou de la capsule les saisies s'appliquent. Est-ce que ça ne serait pas intéressant de réfléchir en ce sens ? Ca complexifie un peu les traitements mais une fois que c'est fait c'est plus souple. La question c'est le pipeline renvoit-il des saisies complètes ou seulement les informations nécessaires (surtout si remplacement). ?
Le 23/02/2019 à 13:09, @Eric a écrit :
Hello les amis,
J'ai fait quelques modifications dans le formulaire editer_noisette pour unifier le traitements des saisies de la noisette et de la capsule en les conservant néanmoins séparées. En tout cas, tout est en PHP. Mon idée est de préparer l'insertion d'un pipeline tel que celui de noizetier_extra. En réfléchissant à son implémentation ce qui me gêne est le manque de déterminisme de la mise en oeuvre et le fait qu'elle ne fonctionne donc que pour css et conteneur_css.
J'ai essayé de créer un pipeline plus générique qui englobe le précédent mais c'est vrai que c'est pas simple de trouver un schéma satisfaisant. En premier lieu, j'ai séparé paramètres de noisette et paramètres de capsule. Ensuite j'ai désigné pour chaque saisie le paramètre de base concerné, à savoir, si je rajoute une saisie de classe pour conteneur_css je désigne explicitement conteneur_css.
Par exemple, voilà la déclaration de test que j'ai utilisée, uniquement pour les paramètres de noisette (index noisette). Pour la capsule il faudrait utiliser l'index 'capsule'. Dans l'exemple ci-dessous je définis pour les paramètres d'un type de noisette "conteneur" :
- remplacement de l'input texte conteneur_css par une sélection de 4 valeurs possibles
- j'ajoute à ce même paramètre conteneur_css une saisie nommée conteneur_css_bis qui viendra s'ajouter au paramètre conteneur_css (ça c'est à priori le cas que vous utilisez)
- et j'ai créé un nouveau paramètre conteneur_css_ter qui viendra j'ajouter à la liste des paramètres.
$saisies_zgala = array( // Paramètres de noisettes 'noisette' => array( 'conteneur' => array( array( 'parametre' => 'conteneur_css', 'saisies' => array( array( 'saisie' => 'selection', 'options' => array( 'nom' => 'conteneur_css', 'label' => 'label de css', 'cacher_option_intro' => 'oui', 'data' => array( 'class1' => 'label de class1', 'class2' => 'label de class2', 'class3' => 'label de class3', 'class4' => 'label de class4', ), ), ), array( 'saisie' => 'input', 'options' => array( 'nom' => 'conteneur_css_bis', 'label' => 'label de css bis', ), ), ), ), array( 'parametre' => 'conteneur_css_ter', 'saisies' => array( array( 'saisie' => 'input', 'options' => array( 'nom' => 'conteneur_css_ter', 'label' => 'label de css ter', ), ), ), ), ), ), );
La séparation noisette / capsule permet en particulier de positionner correctement les nouvelles saisies à proximité des autres. J'ai codé un editer_noisette.php qui intègre le pipeline pour charger et vérifier. Je n'ai pas encore fait le traiter car je voulais vous en parler avant. Ca fonctionne très bien pour créer le formulaire et le vérifier. Pour le traiter c'est pas beaucoup plus compliqué sauf qu'il faut un traitement particulier pour les inputs de classe. Je me suis dit que pour repérer ces inputs il suffirait d'utiliser la vérification et d'utiliser la nouvelle vérification que j'ai rajouté il y a peu attribut_class et donc initier la concaténation comme fait dans noizetier_extra. Dans les autres cas, on fait simple, on remplace ou on ajoute.
Dans le principe je trouve ça plus générique et déterministe mais ça souffre encore de quelques insuffisances comme pour le calcul du champ final suivant la sémantique du paramètre (peut être qu'une fonction de calcul pour chaque sémantique pourrait combler le vide). Donc c'est pour cela que j'ai pas commité et que je vous demande ce que vous en pensez avant d'aller plus loin.
J'attends vos commentaires bienveillants ;-).
Le 24/02/2019 à 15:44, @Eric a écrit :
Bon finalement j'ai un peu travaillé le sujet et j'ai implémenté un truc qui fonctionne à priori. Ca permet de faire ce dont vous avez besoin et aussi ce que je voulais. C'est pas loin de la précédente proposition mais c'est complet et j'ai un peu changé la forme des données dans le pipeline. Je vous joins :
- le fichier editer_noisette.php
- le fichier formater_attribut_class.php à mettre dans inc/
- et un fichier zgala_pipelines.php qui donne la structure commentée des saisies dans le pipeline noizetier_type_noisette_saisies
Pour décider si je dois appeler une fonction de calcul pour ajouter les saisies supplémentaires à un paramètre de base (ceux du YAML) je regarde la vérification dudit paramètre et j'appelle une fonction inc/formater_.php. Donc là pour les classes il faut mettre la vérification attribut_class (c'est déjà le cas pour conteneur_css et c'est pris par défaut pour css de la capsule).
Voilà c'est sympa je trouve, surement que ça fait pas mal de trucs en plus mais finalement est-ce un problème? Je vous laisse me dire ce que vous en pensez et si ok je commite et sinon je brule tout dans un grand autodafé.