Je voudrais partager avec vous un petit retour d’expérience sur la difficulté à personnaliser des formulaires existants qui par nature sont ou devraient être assez génériques.
Je viens de terminer le développement du plugin SVP Typologie, le nouveau module connexe de SVP qui permet aujourd’hui de gérer entièrement les catégories et les tags de plugin. De fait, cette gestion a été extraite de SVP et complètement déléguée à ce nouveau plugin.
Il est donc possible aujourd’hui de migrer sans douleur et sans reprise immédiate de tous les paquet.xml vers les nouvelles catégories. Cela permet aussi d’alléger SVP dans l’objectif de passer un jour à un SVP Composer.
Dans la foulée, SVP API, le module REST qui permet de récupérer les collections plugins et dépôts (et oui ça existe!) a été enrichi avec les collections catégories, tags et affectations (des catégories et des tags aux plugins). Cela permettrait à un site de récupérer les listes et les affectations de catégories et de tags aux plugins si besoin.
Voilà pour un petit état des lieux des travaux SVP.
Pour implémenter les typologies (catégorie et tag) j’ai utilisé les mots-clés techniques et arborescents, les typologies étant matérialisées par des groupes de mots-clés. Rien d’exceptionnel donc et surtout mais cela m’a permis de ne pas tout redévelopper.
Les types d’une typologie, appelés génériquement « types de plugin » sont donc des mots-clés de groupes spécifiques.
Pour définir ou modifier ces types j’ai donc utilisé le formulaire d’édition d’un mot dans une page dédiée (pas mot_edit) en le personnalisant.
Pour le personnaliser j’utilise donc le pipeline formulaire_fond pour intercepter le HTML et le modifier.
La modification est assez compliquée car elle joue sur des REGEXP et des remplacements qui pourraient s’avérer fragiles si on modifiait la structure du formulaire initial.
Rien de rédhibitoire mais pas super friendly.
Et là je me suis dit que si le formulaire était décrit en PHP avec Saisies ça simplifierait énormément les choses.
On jouerait juste sur des tableaux ou des index.
Alors je n’ai jamais été un fanatique de Saisies (surtout le YAML) mais en l’occurrence pour des formulaires un peu génériques je trouve que c’est un plus indéniable et cela apporte de la simplicité et de la robustesse au code de personnalisation.
Ne faudrait-il pas envisager une telle migration pour un certains nombre de formulaires.
Franchement, un tableau PHP de Saisies est tout à fait lisible de mon point de vue.
Maintenant, ça forcerait à intégrer Saisies au plugins du Core (débat récurrent) et donc à stabiliser son développement voire à le découper un peu comme N-Core et Noizetier pour n’y intégrer qu’un noyau et pas toutes les saisies qui fleurissent tous les jours.
En tout cas, ça me parait une question à se poser et un projet intéressant.
On a ce débat à chaque fois que la question revient sur la table, mais tant pis, je le redis :
C’est une approche totalement orientée développeur qui me hérisse vraiment le poil car on perd totalement de vue le html, et on fait semblant de croire qu’une interface utilisateur c’est juste de la juxtaposition de blocs standard à la va comme je te pousse.
Résultat on finit avec des formulaires long comme le bras et incompréhensibles (cf de nombreux exemples sur la zone, comme la configuration du menu rubrique arborescent, un cas d’école, ou la configuration des champs de formidable), parce qu’il est tellement plus simple de juste ajouter un nouveau bloc de saisie à chaque besoin, sans se poser la question de comment il s’insère dans l’ergonomie et la vue d’ensemble, et parce que si on avait la moindre envie de modifier un peu l’ergonomie « standard » ça devient immédiatement un calvaire
Bref, je vois bien que la facilité de développement fait que ça finira par arriver dans un moment de faiblesse, mais je pleure d’avance à la pensée de ce jour, cette question de l’accès au HTML étant chaque fois évacuée pour de mauvaises raison au lieu d’être vraiment réfléchie et résolue.
On pourrait par exemple imaginer que le constructeur de formulaire regarde dans le fond html avant de générer la saisie standard, et qu’on puisse avoir un moyen dans ce fond de fournir son propre HTML pour une ou plusieurs saisies (ou pour N saisies d’un coup, pour, par exemple réunir la saisie d’un CP et d’une ville, qui sont intimement liée).
Au moins un mécanisme de ce type permettrait de faire des compromis, et de se concentrer sur des parties spécifiques du formulaire dont on veut personnaliser l’ergonomie (voire de tout le formulaire), sans se retrouver pieds et poings liés à la mise en forme des saisies standard.
--
Cédric
Le 19 juil. 2019 à 09:32 +0200, Eric Lupinacci <eric@smellup.net>, a écrit :
Hello les amis,
Je voudrais partager avec vous un petit retour d'expérience sur la difficulté à personnaliser des formulaires existants qui par nature sont ou devraient être assez génériques.
Je viens de terminer le développement du plugin SVP Typologie, le nouveau module connexe de SVP qui permet aujourd'hui de gérer entièrement les catégories et les tags de plugin. De fait, cette gestion a été extraite de SVP et complètement déléguée à ce nouveau plugin.
Il est donc possible aujourd'hui de migrer sans douleur et sans reprise immédiate de tous les paquet.xml vers les nouvelles catégories. Cela permet aussi d'alléger SVP dans l'objectif de passer un jour à un SVP Composer.
Dans la foulée, SVP API, le module REST qui permet de récupérer les collections plugins et dépôts (et oui ça existe!) a été enrichi avec les collections catégories, tags et affectations (des catégories et des tags aux plugins). Cela permettrait à un site de récupérer les listes et les affectations de catégories et de tags aux plugins si besoin.
Voilà pour un petit état des lieux des travaux SVP.
Pour implémenter les typologies (catégorie et tag) j'ai utilisé les mots-clés techniques et arborescents, les typologies étant matérialisées par des groupes de mots-clés. Rien d'exceptionnel donc et surtout mais cela m'a permis de ne pas tout redévelopper.
Les types d'une typologie, appelés génériquement "types de plugin" sont donc des mots-clés de groupes spécifiques.
Pour définir ou modifier ces types j'ai donc utilisé le formulaire d'édition d'un mot dans une page dédiée (pas mot_edit) en le personnalisant.
Pour le personnaliser j'utilise donc le pipeline formulaire_fond pour intercepter le HTML et le modifier.
La modification est assez compliquée car elle joue sur des REGEXP et des remplacements qui pourraient s'avérer fragiles si on modifiait la structure du formulaire initial.
Rien de rédhibitoire mais pas super friendly.
Et là je me suis dit que si le formulaire était décrit en PHP avec Saisies ça simplifierait énormément les choses.
On jouerait juste sur des tableaux ou des index.
Alors je n'ai jamais été un fanatique de Saisies (surtout le YAML) mais en l'occurrence pour des formulaires un peu génériques je trouve que c'est un plus indéniable et cela apporte de la simplicité et de la robustesse au code de personnalisation.
Ne faudrait-il pas envisager une telle migration pour un certains nombre de formulaires.
Franchement, un tableau PHP de Saisies est tout à fait lisible de mon point de vue.
Maintenant, ça forcerait à intégrer Saisies au plugins du Core (débat récurrent) et donc à stabiliser son développement voire à le découper un peu comme N-Core et Noizetier pour n'y intégrer qu'un noyau et pas toutes les saisies qui fleurissent tous les jours.
En tout cas, ça me parait une question à se poser et un projet intéressant.
Le 19/07/2019 à 09:31, Eric Lupinacci a écrit :>> Et là je me suis dit que si le formulaire était décrit en PHP avec Saisies> ça simplifierait énormément les choses.> On jouerait juste sur des tableaux ou des index.
Perso, malgré le fait que j'utilise saisies tout le temps, je n'ai jamais accroché à ce type de déclaration des formulaires en php et je ne l'utilise pas, je ne suis donc vraiment pas chaud pour l'utiliser dans le core.
Bé vu que c'est mon avis depuis que j'ai introduit l'API PHP de Saisies
il y a… 9 ans, je vais pas dire le contraire.
Moi je suis tout à fait d'accord qu'il y a des manques encore pour
permettre de personnaliser plus facilement et plus en détail (surtout :
pouvoir personnaliser le HTML "base" ou de telle saisie non pas que pour
tout le site, mais pour tel formulaire, ou tel ensemble de formulaires).
Mais les manques ça se travaille, et ya rien d'immensément compliqué à
ajouter.
Ce point des quelques manques mis à part, je pense qu'absolument tous
les formulaires des objets génériques devraient être en Saisies. Ça
permet des choses vraiment utiles et super en personnalisation :
- pouvoir personnaliser l'aide immédiate d'un formulaire précis, les
labels et explications d'un champ (c'est la manière prioritaire de faire
de l'aide en ligne : au plus près des champs)
- pouvoir travailler de manière automatisé sur tous les champs de tous
les formulaires : changer l'ordre des champs, insérer les champs extras
où on veut et non pas uniquement tout à la fin (si on veut insérer un
champ extra après le titre, on pourrait), là encore en ergonomie c'est
le mieux
- pouvoir faire des plugins génériques qui connaissent le "type" de
chaque champ des objets, car avec l'API objet, on connait
"champs_editables" mais ça ne dit pas si ce sont des nombres, des
textes, etc, j'ai par exemple fait un jour un plugin de "propositions de
modifications" qui avait une interface "côte à côte" montrant le "diff"
entre une proposition et la version publiée : le diff de chaque champ
était alors affiché différemment suivant le type de saisie
- on peut imaginer d'autres choses dans le genre comme un plugin qui
permet de configurer quels champs sont vraiment utilisés, pour tous les
objets, de manière générique (comme pour la config des articles "sous
titre" ou pas etc), et même de manière fine, genre qui a le droit de
voir chaque champ (l'admin peut éditer le descriptif, mais pas le
rédacteur, etc), enfin vraiment plein plein d'extension possible qui
seraient totalement inimaginables avec que du HTML en dur
Donc oui on peut :
1) optimiser le code, la rapidité d'exécution, etc
2) combler les quelques manques qui permettrait d'encore mieux
personnaliser le HTML pour tel formulaire précis, et cela sans toucher
au PHP donc convenant parfaitement aux simples intégrateurs HTML (de la
surcharge basique)
(je ne pense pas qu'il y ait besoin de découper à outrance, Saisies
étant déjà juste une API = ne produisant rien nulle part ni en admin ni
en public tant qu'on ne l'utilise pas)
J'avais l'idée un jour de faire un plugin proof of concept
"saisies-core" ou "saisies-dist" qui surchargerait tous les formulaires
du noyau et des plugins-dist, tous les objets les plugins connus
(événement aussi), entièrement en Saisies PHP.
Je voudrais partager avec vous un petit retour d'expérience sur la difficulté à personnaliser des formulaires existants qui par nature sont ou devraient être assez génériques.
Merci pour ce travail. Concernant la question de saisies : il y a les remarques de Cédric, pour lesquelles je suis en partie d'accord, en partie pas,et en partie je comprend pas.
Mais il y aussi je pense un travail encore d'épurage pour mettre cela dans le core.
Il se trouve que je comptais ce week-end aborder enfin la question de la refactorisation / remise au propre de la partie JS d'affiche_si.
C'est un point parmis d'autres, mais il y a je pense trop de bazar actuellement dans saisie pour une intégration "tel que" dans le core.
Sans compter qu'à mon sens il faudrait idéalement transformer les saisies en objet PHP (quitte à avoir une déclaration PHP, autant avant des outils pour mieux les manipuler).
Le ven. 19 juil. 2019 à 10:53, Cerdic <cedric@yterium.com> a écrit :
Hello,
On a ce débat à chaque fois que la question revient sur la table, mais
tant pis, je le redis :
Quand j'ai écrit mon mail je me suis dit que je m'aventurais sur un terrain
glissant.
Par contre, je me disais qu'avec le temps...
Et si on reparlait de l'interface privée ?
Plus sérieusement je me rappelle d'une discussion sur saisies comparé à #INCLUDE uniquement et l'explication de esj.
Je ne me rappelle plus d'autre chose.
C’est une approche totalement orientée développeur qui me hérisse vraiment
le poil car on perd totalement de vue le html, et on fait semblant de
croire qu’une interface utilisateur c’est juste de la juxtaposition de
blocs standard à la va comme je te pousse.
Oui c'est exact, on perd de vue le HTML, c'est ce qui me gêne aussi, par
contre non, je ne suis pas d'accord avec ton procès d'intention sur
l'absence de réflexion UX ou UI.
Si je prends le cas qui m'a amené à faire le mail je me suis dit : en
partant du formulaire d'édition d'un mot, comment créer un formulaire
d'édition d'un type de plugin qui est un mot, avec un identifiant chaine
unique (champ obligatoire supplémentaire à mettre en premier), dans un
groupe spécial déjà identifié quand on arrive dans le formulaire (champ à
cacher) ayant un parent ou pas (champ à modifier)...
Cela m'a amené à utiliser le pipeline formulaire_fond pour écrire le code
suivant :
// Insertion de l'identifiant avant le titre
$saisie_identifiant =
recuperer_fond('formulaires/inclure/inc-type_plugin_identifiant',
$env);
// Remplacement de la saisie du mot parent par celle du type parent.
// -- on complète l'environnement avec la typologie et le groupe
principalement utile pour la création
include_spip('inc/config');
$typologies = lire_config('svptype/typologies', array());
foreach ($typologies as $_typologie => $_config) {
if ($_config['id_groupe'] == $id_groupe) {
$env['typologie'] = $_typologie;
break;
}
}
$saisie_parent =
recuperer_fond('formulaires/inclure/inc-type_plugin_parent', $env);
// Remplacement de la sélection du groupe de mots par un hidden avec
l'id du groupe.
$hidden_id_groupe = "<input type=\"hidden\" name=\"id_groupe\"
value=\"${id_groupe}\">";
Pas forcément compliqué mais pas vraiment limpide non plus et on perd aussi
la vision du HTML final en utilisant le pipeline.
Je ne pouvais pas (ou je n'ai pas su?) réécrire le HTML du formulaire car
je ne voulais pas perturber les autres mots-clés.
J'avais déjà eu une galère avec d'autres formulaires un peu standard
(liens_auteurs je crois) quand j'avais fait le plugin relecture et que je
voulais ajouter un relecteur à un article en renommant le titre du
formulaire il me semble.
Résultat on finit avec des formulaires long comme le bras et
incompréhensibles (cf de nombreux exemples sur la zone, comme la
configuration du menu rubrique arborescent, un cas d’école, ou la
configuration des champs de formidable), parce qu’il est tellement plus
simple de juste ajouter un nouveau bloc de saisie à chaque besoin, sans se
poser la question de comment il s’insère dans l’ergonomie et la vue
d’ensemble, et parce que si on avait la moindre envie de modifier un peu
l’ergonomie « standard » ça devient immédiatement un calvaire
Je viens de répondre au dessus, ce n'est pas forcément le cas ni le but,
mon formulaire est plus simple que le formulaire initial.
Bref, je vois bien que la facilité de développement fait que ça finira par
arriver dans un moment de faiblesse, mais je pleure d’avance à la pensée de
ce jour, cette question de l’accès au HTML étant chaque fois évacuée pour
de mauvaises raison au lieu d’être vraiment réfléchie et résolue.
Non, ce n'est pas mon propos et je m'excuse d'avoir enfreint ma
philosophie, à savoir, proposer une solution ou un embryon de solution à
une question fonctionnelle ouverte.
C'est vrai que Saisies existe et que ce pourrait être une solution mais la
vrai question est : comment pourrait-on faire pour simplifier ces
personnalisations c'est mon seul objectif.
Je voudrais juste quand même que vous imaginiez pour quelqu'un qui ne passe
pas sa journée sur SPIP les heures et les heures que je passe à comprendre
ou re-comprendre certains mécanismes de SPIP perdus dans le code de SPIP ou
de plugins sachant qu'il existe souvent des façons alternatives qui loin de
simplifier les choses me laisse perplexe sur quoi faire.
On pourrait par exemple imaginer que le constructeur de formulaire regarde
dans le fond html avant de générer la saisie standard, et qu’on puisse
avoir un moyen dans ce fond de fournir son propre HTML pour une ou
plusieurs saisies (ou pour N saisies d’un coup, pour, par exemple réunir la
saisie d’un CP et d’une ville, qui sont intimement liée).
Au moins un mécanisme de ce type permettrait de faire des compromis, et de
se concentrer sur des parties spécifiques du formulaire dont on veut
personnaliser l’ergonomie (voire de tout le formulaire), sans se retrouver
pieds et poings liés à la mise en forme des saisies standard.
Oui c'est surement ce que j'aurais utilisé dans mon cas car le plus
compliqué c'est de cibler la ou les saisies ou composants de saisie.
Je suis agnostique quant à la solution si on avance vers une simplification
des mécanismes actuels.
Mais c'est vrai que travailler du HTML par regexp dans du PHP est notoire
inconfortable et instable.
