[SPIP Zone] [Spip-zone-commit] r102777 - _plugins_/produits/trunk/formulaires

Archives Zone
1

Ah la vache NOOOOOOOON !!!

On avait un formulaire HTML EDITABLE ET MODIFIABLE ET COMPREHENSIBLE, et adapté à l'usage du point de vue ergo (cf produit physique oui/non, dimensions)

C'est pas pour y coller le truc incompréhensible des saisies et qui rend tout adaptation visuelle et ergo au besoin absolument impossible.

Je demande le revert immédiat de ce commit, c'est une régression ergonomique et fonctionnelle et de maintenabilité.

--
Cédric

spip-zone-commit@rezo.net a écrit :

Author: p@henix.be
Date: 2017-02-09 08:32:21 +0100 (Thu, 09 Feb 2017)
New Revision: 102777

Modified:
    _plugins_/produits/trunk/formulaires/editer_produit.html
    _plugins_/produits/trunk/formulaires/editer_produit.php
Log:
Utiliser une saisie php à la place de tout ce code HTML

Cela :

- adapte le code html au nouvelle norme (div/li)
- Corrige les bugs d'affichage sous SPIP 3.1
- Rend le code lisible :slight_smile:

Details: Connexion · GitLab

_______________________________________________
Spip-zone-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone-commit

2

Le 09/02/2017 à 09:53, Cédric Morin a écrit :

On avait un formulaire HTML EDITABLE ET MODIFIABLE ET COMPREHENSIBLE, et
adapté à l'usage du point de vue ergo (cf produit physique oui/non,
dimensions)

C'est pas pour y coller le truc incompréhensible des saisies et qui rend
tout adaptation visuelle et ergo au besoin absolument impossible.

Je suis tout à fait d'accord avec "adapté à l'usage du point de vue ergo".

Tant que Saisies ne permet pas de personnaliser comme on veut (en mettant plusieurs saisies sur la même ligne, en permettant de personnaliser telle saisie pour tel formulaire précis, etc), et bien quand on a un besoin d'ergonomie particulier, pour l'instant c'est mieux le HTML direct.

<troll>
Par contre pour tout le reste, je suis désolé mais c'est factuellement illisible. :stuck_out_tongue:
Comparée aux 4 mini lignes de chaque saisie, hyper claires avec juste le type de la saisie et ses 2 ou 3 options… Le sens de chaque ligne est compréhensible par tout le monde y compris non-dev en 2s chrono.

(Et je prévois depuis un certain temps de permettre ces personnalisations ergonomiques dans Saisies…)

(Non il n'y a pas de fin de `<troll>`.)

--
RastaPopoulos

3

Le 09/02/2017 à 17:04, RastaPopoulos a écrit :

Le 09/02/2017 à 09:53, Cédric Morin a écrit :

On avait un formulaire HTML EDITABLE ET MODIFIABLE ET COMPREHENSIBLE, et
adapté à l'usage du point de vue ergo (cf produit physique oui/non,
dimensions)

C'est pas pour y coller le truc incompréhensible des saisies et qui rend
tout adaptation visuelle et ergo au besoin absolument impossible.

Je suis tout à fait d'accord avec "adapté à l'usage du point de vue ergo".

Tant que Saisies ne permet pas de personnaliser comme on veut (en
mettant plusieurs saisies sur la même ligne, en permettant de
personnaliser telle saisie pour tel formulaire précis, etc), et bien
quand on a un besoin d'ergonomie particulier, pour l'instant c'est mieux
le HTML direct.

Hum.

Ce qui me gène avec les saisies PHP c'est que c'est difficile effectivement dès que tu veux modifier un champ pour un formulaire, ou générer un html un peu différent à des endroits.

Ceci dit Pour moi `#SAISIE` est un compromis satisfaisant et `#SAISIE` ou des saisies en PHP restent tout de même vachement plus lisibles et moins sources de bugs.

Ce qui gène c'est que du coup on n'a pas la main sur le HTML généré. Dans certains cas c'est ennuyant. Mais mince, coller des pavés de html c'est pas lisible, alors «le bon vieux html»… Bref, vive `#SAISIE` ^^

Par rapport à ce que tu dis Rasta pour avoir des éléments sur une ligne, peut être déjà qu'il faut prévoir d'augmenter la référence de la syntaxe HTML avec de nouveaux cas.

En plus d'avoir un mode "fieldset" il pourrait y avoir un mode "ligne" peut être. Pour pouvoir mettre 3 saisies côtes à côtes.

C'est d'ailleurs quelque chose comme cela qu'avait écrit Cerdic

<li class="editer editer_dimensions pleine_largeur">
   <div class="line">
     <div class="editer_poids unit size1of4>

ça pourrait être maintenant

<div class="editer-groupe ligne">
     <div class="editer" ...>

Et dans les déclarations PHP de saisies du coup, il faudrait prévoir cela, peut être avec une saisie spéciale "groupe de champs en ligne" comme on a déjà la saisie "groupe de champs" (fieldset).

Et pour la surcharge en fonction du formulaire, ça voudrait dire qu'il faut transmettre l'info du nom du formulaire aux `#SAISIE` ce qui n'est pas si évident je crois bien.

MM.

4

Le 09/02/2017 à 18:39, Matthieu Marcillaud a écrit :

Ce qui me gène avec les saisies PHP c'est que c'est difficile
effectivement dès que tu veux modifier un champ pour un formulaire, ou
générer un html un peu différent à des endroits.

Non ce n'est pas difficile. Ce n'est encore actuellement permis par le plugin, mais je pense que ça prendrait très peu de temps à l'ajouter et on avait déjà discuté de ce sujet tous les deux.

Ceci dit Pour moi `#SAISIE` est un compromis satisfaisant et `#SAISIE`
ou des saisies en PHP restent tout de même vachement plus lisibles et
moins sources de bugs.

Oui, moins de bugs, comportement cohérent partout, et en PHP : déclaration explicite et programmable des champs, ce qui permet à des plugins de les manipuler pour insérer ou modifier des champs.

Par rapport à ce que tu dis Rasta pour avoir des éléments sur une ligne,
peut être déjà qu'il faut prévoir d'augmenter la référence de la syntaxe
HTML avec de nouveaux cas.

Oui d'où ma parenthèse : ce sont des choses que j'ai en tête, et une des possibilités est d'ajouter un nouveau "conteneur" sur le même schéma que pour les "fieldset", mais pour mettre en ligne, ou en colonne, plusieurs champs… (que ce soit par float, table ou flexbox, ce sera à voir, mais peu importe l'implémentation finale).

Et pour la surcharge en fonction du formulaire, ça voudrait dire qu'il
faut transmettre l'info du nom du formulaire aux `#SAISIE` ce qui n'est
pas si évident je crois bien.

On en a déjà discuté, mais en tout cas avec l'API PHP, il n'est à mon avis pas compliqué d'ajouter l'envoi optionnel d'un "identifiant" de formulaire, et alors :
- s'il y a une saisie spécifique pour lui, on prend en priorité (saisies/XXX_input.html ou bien saisies/XXX/input.html…)
- sinon prendre celui par défaut
Ça ne parait pas insurmontable.

--
RastaPopoulos