Hello,

Le ven. 19 juil. 2019 à 10:53, Cerdic <ced...@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);

$cherche = 
"/(<(li|div)[^>]*class=(?:'|\")editer-groupe[^>]*>)\s*(<(li|div)[^>]*class=(?:'|\")editer
editer_titre)/is";
if (preg_match($cherche, $flux['data'], $m)) {
   $flux['data'] = preg_replace(
      $cherche,
      '$1' . "\n${saisie_identifiant}" . '$3',
      $flux['data'],
      1
   );
}

// 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);

$cherche = "/(<(li|div)[^>]*class=(?:'|\")editer
editer_id_parent.*?<\/\\2>)/is";
if (preg_match($cherche, $flux['data'], $m)) {
   $flux['data'] = preg_replace(
      $cherche,
      $saisie_parent,
      $flux['data'],
      1
   );
}

// 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}\">";

$cherche = "/(<(li|div)[^>]*class=(?:'|\")editer
editer_groupe_mot.*?<\/\\2>)/is";
if (preg_match($cherche, $flux['data'], $m)) {
   $flux['data'] = preg_replace(
      $cherche,
      $hidden_id_groupe,
      $flux['data'],
      1
   );
}

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.

++
Eric
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Répondre à