Pour moi c'est exactement le contraire, ça rajoute une surcouche liée à la logique de saisies sur ce qui est normalement du HTML bien plus comprehensible et lisible et facile à adapter au besoin.
En l'occurence ici on a une parfaite illustration de ce qui est detestable : on remplace un formulaire dont l'ergo de la saisie avait été adaptée pour la partie dimensions, physique/immatériel par un truc totalement standard, informe et 10x moins ergonomique.
Je vais quand même essayer de défendre mon adaptation.
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 toujours le cas. Saisies produit du HTML qu'on peux éditer via la fonction formulaire. Je veux bien concéder qu'on perd un peux de liberté sur le html, mais la personnalisation éventuel viendra du CSS, que l'on peux, à loisir, éditer.
D'un point de vue ergonomique ma version avec saisies reproduit le mécanisme d'ouverture/fermeture de la case à coché "dématérialisé".
Quand au champs, largeur/longueur/hauteur, ils étaient complètement buggés sous SPIP 3.1.3, les label était illisible.
La personnalisation ergonomique ? Je préfère que les labels soit bien lisible plutôt que d'avoir un truc personnalisé, qui plus est une personnalisation assez simpliste qui n'apporte somme toute pas grand chose (a part des problèmes de maintenabilité).
C'est pas pour y coller le truc incompréhensible des saisies et qui rend tout adaptation visuelle et ergo au besoin absolument impossible.
On passe de ceci :
à ceci :
Cet argument me semble complètement irrationnel, pourquoi la version HTML serait elle meilleur que la version Saisie PHP ? Les deux sont complexe en fonction de différent paramètre. La version PHP est juste plus durable (j'y reviendrai).
Je me suis déjà exprimé sur l'aspect ergonomique, j'ajouterai ici que si un besoin ergonomique ce fait soudain sentir, c'est sur saisie qu'il faut agir afin que tout le monde puisse profiter des avancées ergonomiques.
En l'occurence ici on a une parfaite illustration de ce qui est detestable : on remplace un formulaire dont l'ergo de la saisie avait été adaptée pour la partie dimensions, physique/immatériel par un truc totalement standard, informe et 10x moins ergonomique.
Pourrais-tu m'expliquer, en quoi le faite que les champs largueur/longueur/hauteur soit l'un à coté de l'autre plutôt que l'un en dessous de l'autre améliore l'ergonomie ? En quoi c'est 10x plus ergonomique ?
Je dirais qu'ils ont un peu tendance à jeter un certain doute : l'ordre c'est largeur/longueur/hauteur ? Ou bien Hauteur/largeur/longueur ?
Je voudrai aussi qu'on prennent en compte le très gros avantage que représente Saisie : la mutualisation du code des formulaires.
Cela permet d'avoir une certain garantie sur l'avenir des formulaires qui continueront de fonctionner au fil des versions de SPIP, car Saisie sera adapté.
Cela permet aussi d'avoir un homogénéité dans les formulaires, et évite les erreurs humaines dans le HTML.
Le cas présent est une parfaite illustration du problème : un formulaire non fonctionnel car fait "à la main" et qui s'affichait mal avec la nouvelle version de SPIP. En utilisant Saisie, ce problème disparaît.
Didier
Le 09/02/17 à 09:59, Cédric Morin a écrit :
spip-zone-commit@rezo.net a écrit :
- Rend le code lisible:)
Pour moi c'est exactement le contraire, ça rajoute une surcouche liée à la logique de saisies sur ce qui est normalement du HTML bien plus comprehensible et lisible et facile à adapter au besoin.
En l'occurence ici on a une parfaite illustration de ce qui est detestable : on remplace un formulaire dont l'ergo de la saisie avait été adaptée pour la partie dimensions, physique/immatériel par un truc totalement standard, informe et 10x moins ergonomique.
je plussoie dans le sens des remarques de Didier. Personnellement en lisant la version PHP, je vois tout de suite à quoi correspond chaque ligne…
--
Maïeul
On risque de jouer longtemps à ça donc vu que le formulaires était le résultat de
Un formulaire HTML est entièrement malléable, il permet de faire ce qu'on veut en HTML et de coller aux besoins. Il permet aussi de maitriser le HTML qui sera rendu.
Les saisies sont un outil sans doute très pratique pour le développeur, mais qui forcent à se fondre dans leur moule. C'est un choix et je n'aime pas la tournure que ça force à adopter. Parce qu'on a commencé en SAISIES, quand se présente le cas complexe qu'elles ne savent pas gérer on a pas le courage de tout refaire en HTML alors on paresse, on fait un truc merdouilleux et c'est l'utilisateur qui trinque.
Le plugin produit est a mon sens embryonnaire, il va devoir évoluer car il y a plein de choses qu'il gère pas, et les saisies ne sont pas adaptées à tous les cas particulier qu'il va falloir gérer.
Je suis passé en HTML pour amener une évolution et ouvrir des portes pour la suite du développement.
Tu ramènes tout en tableau de saisies juste pour corriger un défaut d'affichage, par pur préférence, sans aucune justification fonctionnelle, et qui plus est en introduisant un changement de comportement sur la rubrique qui devient obligatoire alors qu'elle ne l'a jamais été.
Tout ça est contre-productif.
--
Cédric
Debondt Didier a écrit :
Bonjour Cédric,
Je vais quand même essayer de défendre mon adaptation.
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 toujours le cas. Saisies produit du HTML qu'on peux éditer via la
fonction formulaire. Je veux bien concéder qu'on perd un peux de liberté
sur le html, mais la personnalisation éventuel viendra du CSS, que l'on
peux, à loisir, éditer.
D'un point de vue ergonomique ma version avec saisies reproduit le
mécanisme d'ouverture/fermeture de la case à coché "dématérialisé".
Quand au champs, largeur/longueur/hauteur, ils étaient complètement
buggés sous SPIP 3.1.3, les label était illisible.
La personnalisation ergonomique ? Je préfère que les labels soit bien
lisible plutôt que d'avoir un truc personnalisé, qui plus est une
personnalisation assez simpliste qui n'apporte somme toute pas grand
chose (a part des problèmes de maintenabilité).
C'est pas pour y coller le truc incompréhensible des saisies et qui
rend tout adaptation visuelle et ergo au besoin absolument impossible.
Cet argument me semble complètement irrationnel, pourquoi la version
HTML serait elle meilleur que la version Saisie PHP ? Les deux sont
complexe en fonction de différent paramètre. La version PHP est juste
plus durable (j'y reviendrai).
Je me suis déjà exprimé sur l'aspect ergonomique, j'ajouterai ici que si
un besoin ergonomique ce fait soudain sentir, c'est sur saisie qu'il
faut agir afin que tout le monde puisse profiter des avancées ergonomiques.
En l'occurence ici on a une parfaite illustration de ce qui est
detestable : on remplace un formulaire dont l'ergo de la saisie avait
été adaptée pour la partie dimensions, physique/immatériel par un truc
totalement standard, informe et 10x moins ergonomique.
Pourrais-tu m'expliquer, en quoi le faite que les champs
largueur/longueur/hauteur soit l'un à coté de l'autre plutôt que l'un en
dessous de l'autre améliore l'ergonomie ? En quoi c'est 10x plus
ergonomique ?
Je dirais qu'ils ont un peu tendance à jeter un certain doute : l'ordre
c'est largeur/longueur/hauteur ? Ou bien Hauteur/largeur/longueur ?
Je voudrai aussi qu'on prennent en compte le très gros avantage que
représente Saisie : la mutualisation du code des formulaires.
Cela permet d'avoir une certain garantie sur l'avenir des formulaires
qui continueront de fonctionner au fil des versions de SPIP, car Saisie
sera adapté.
Cela permet aussi d'avoir un homogénéité dans les formulaires, et évite
les erreurs humaines dans le HTML.
Le cas présent est une parfaite illustration du problème : un formulaire
non fonctionnel car fait "à la main" et qui s'affichait mal avec la
nouvelle version de SPIP. En utilisant Saisie, ce problème disparaît.
Didier
Le 09/02/17 à 09:59, Cédric Morin a écrit :
spip-zone-commit@rezo.net a écrit :
- Rend le code lisible:)
Pour moi c'est exactement le contraire, ça rajoute une surcouche liée
à la logique de saisies sur ce qui est normalement du HTML bien plus
comprehensible et lisible et facile à adapter au besoin.
En l'occurence ici on a une parfaite illustration de ce qui est
detestable : on remplace un formulaire dont l'ergo de la saisie avait
été adaptée pour la partie dimensions, physique/immatériel par un truc
totalement standard, informe et 10x moins ergonomique.
Tu ramènes tout en tableau de saisies juste pour corriger un défaut
d'affichage, par pur préférence, sans aucune justification
fonctionnelle, et qui plus est en introduisant un changement de
comportement sur la rubrique qui devient obligatoire alors qu'elle ne
l'a jamais été.
Tout ça est contre-productif.
Surtout que une ligne de css dans le html du form aurait résolu le problème d'affichage :
.editer_dimensions .unit label{margin-left: 0;}
j'dis ça j'dis rien > en bon feignant je préfère taper une ligne de css que de réécrire un array de 15km de long
Après la question c'est pourquoi il y'a eut d'introduit une css
label {
margin-left -130px ??
}
j'ai pas investigué plus loin, mais ça me parait intéressant de savoir
Pour ce qui est des array de description des saisies, j'ai utilisé un temps avant de me rendre compte que c'était plus bloquant qu'autre chose et pas forcément lisible car moins compacte.
Quand a la "stabilité" ajoutée par saisie, qu'advient il si (comme moi parfois) on surcharge le modèle _base, ou une autre pour une utilisation x ou Y dans un framework css ?
Tiens, parlons justification fonctionnelle pour le plugin Produits en particulier. C'est typiquement un plugin qui risque fort d'être "complémenté" par divers sous-plugins suivants les workflows, suivant les types de produits, avec un plugin de "variantes", etc. Et ces plugins vont devoir parfois ajouter des champs ou modifier ou remplacer des champs existants par d'autres plus complexes, etc. L'API de manipulation des champs de Saisies est exactement adaptée pour cela. Alors qu'avec du HTML en vrac à l'arrache, il n'est pas possible de cibler tel champ pour le remplacer, modifier, ou pour insérer des choses à un endroit précis, etc.
C'est tout l'intérêt d'une vraie API de déclaration explicite de champs pour tous les formulaires. C'est le choix fait dans Drupal, et pour ce point je suis d'accord avec leur approche.
Cela permet des fonctionnalités génériques de manipulation pour que des plugins externes puissent modifier les comportements des formulaires à loisir. Et ce pour des dizaines de besoins différents… Ça me parait plus important (et beaucoup plus courant !) que de permettre à un⋅e très hypothétique non-dev qui aurait envie de personnaliser un formulaire d'édition d'un objet qui a 99% du temps va être éditer dans l'admin de SPIP. Autrement dit, le fait de permettre des fonctionnalités de modifications avancées me parait plus courant et plus important qu'une hypothétique personnalisation HTML (et qui en plus pourrait être permise par Saisies en l'améliorant un peu).
On risque de jouer longtemps à ça donc vu que le formulaires était le résultat de
Tu ramènes tout en tableau de saisies juste pour corriger un défaut d’affichage, par pur préférence, sans aucune justification fonctionnelle, et qui plus est en introduisant un changement de comportement sur la rubrique qui devient obligatoire alors qu’elle ne l’a jamais été.
Tout ça est contre-productif.
Ha !
Tu ramène tout un formulaire HTML juste pour une éventuel personnalisation futur, par pur préférence, sans aucune justification fonctionnelle.
Tout ça est contre-productif. La rubrique qui est devenue obligatoire, c’est une erreur qui n’a rien a voir avec la discutions actuel, je vais d’ailleurs revert ce commit.
Cela fonctionne aussi dans ce sens…
Je constate que tu ne réponds pas beaucoup à mes questions :
En l’occurence ici on a une parfaite illustration de ce qui est detestable : on remplace un formulaire dont l’ergo de la saisie avait été adaptée pour la partie dimensions, physique/immatériel par un truc totalement standard, informe et 10x moins ergonomique.
Pourrais-tu m’expliquer, en quoi le faite que les champs largueur/longueur/hauteur soit l’un à coté de l’autre plutôt que l’un en dessous de l’autre améliore l’ergonomie ? En quoi c’est 10x plus ergonomique ?
Je dirais qu’ils ont un peu tendance à jeter un certain doute : l’ordre c’est largeur/longueur/hauteur ? Ou bien Hauteur/largeur/longueur ?
Ce mail soulève d’autres questions de ma part :
Les saisies sont un outil sans doute très pratique pour le développeur, mais qui forcent à se fondre dans leur moule. C’est un choix et je n’aime pas la tournure que ça force à adopter. Parce qu’on a commencé en SAISIES, quand se présente le cas complexe qu’elles ne savent pas gérer on a pas le courage de tout refaire en HTML alors on paresse, on fait un truc merdouilleux et c’est l’utilisateur qui trinque.
Le plugin produit est a mon sens embryonnaire, il va devoir évoluer car il y a plein de choses qu’il gère pas, et les saisies ne sont pas adaptées à tous les cas particulier qu’il va falloir gérer.
Je suis passé en HTML pour amener une évolution et ouvrir des portes pour la suite du développement.
Aurais-tu un cas réel ou cela ce produit ? Car personnellement je ne me suis jamais retrouvé limité par saisies et j’ai toujours réalisé les interfaces de formulaire que je voulais.
je pense également qu’avoir des formulaires trop complexe n’est pas une bonne chose pour l’utilisateur qui pourrait ce retrouver perdu dans une interface qu’il ne comprend pas…
Je ne comprend pas bien tes objections
mais les SAISIES sont plus coûteuses que le HTML en CPU pour le compilateur
et peut être c'est par là qu'elles devraient être améliorées ?
JLuc
Le 09/02/2017 à 18:06, Cédric Morin a écrit :
On risque de jouer longtemps à ça donc vu que le formulaires était le résultat de Connexion · GitLab
Un formulaire HTML est entièrement malléable, il permet de faire ce qu'on veut en HTML et de coller aux besoins. Il
permet aussi de maitriser le HTML qui sera rendu.
Les saisies sont un outil sans doute très pratique pour le développeur, mais qui forcent à se fondre dans leur moule.
C'est un choix et je n'aime pas la tournure que ça force à adopter. Parce qu'on a commencé en SAISIES, quand se présente
le cas complexe qu'elles ne savent pas gérer on a pas le courage de tout refaire en HTML alors on paresse, on fait un
truc merdouilleux et c'est l'utilisateur qui trinque.
Le plugin produit est a mon sens embryonnaire, il va devoir évoluer car il y a plein de choses qu'il gère pas, et les
saisies ne sont pas adaptées à tous les cas particulier qu'il va falloir gérer.
Je suis passé en HTML pour amener une évolution et ouvrir des portes pour la suite du développement.
Tu ramènes tout en tableau de saisies juste pour corriger un défaut d'affichage, par pur préférence, sans aucune
justification fonctionnelle, et qui plus est en introduisant un changement de comportement sur la rubrique qui devient
obligatoire alors qu'elle ne l'a jamais été.
Tout ça est contre-productif.
Il y a plusieurs points concernant les saisies mais, de ce que j’ai cru comprendre, le souci n’est pas à ce niveau :
Ce que pointe Cédric est que le webmestre ou l’intégrateur puisse adapter à ses besoins et sa charte graphique etc.
Comme il dit, c’est pratique pour nous, et comme dit MM plus rapide et plus facile à lire etc. Mais c’est moins flexible pour les webmestres et ce n’est pas le but recherché.
Je ne comprend pas bien tes objections
mais les SAISIES sont plus coûteuses que le HTML en CPU pour le
compilateur
et peut être c'est par là qu'elles devraient être améliorées ?
Il y a plusieurs points concernant les saisies mais, de ce que j'ai cru
comprendre, le souci n'est pas à ce niveau :
Le 09/02/2017 à 18:06, Cédric Morin a écrit :
Un formulaire HTML est entièrement malléable, il permet de faire
ce qu'on veut en HTML et de coller aux besoins. Il permet aussi
de maitriser le HTML qui sera rendu.
Ce que pointe Cédric est que le webmestre ou l'intégrateur puisse
adapter à ses besoins et sa charte graphique etc.
Les saisies sont un outil sans doute très pratique pour le
développeur, mais qui forcent à se fondre dans leur moule.
Comme il dit, c'est pratique pour nous, et comme dit MM plus rapide et
plus facile à lire etc. Mais c'est moins flexible pour les webmestres et
ce n'est pas le but recherché.
C'est un choix et je n'aime pas la tournure que ça force à
adopter. Parce qu'on a commencé en SAISIES, quand se présente
le cas complexe qu'elles ne savent pas gérer on a pas le courage
de tout refaire en HTML alors on paresse, on fait un
truc merdouilleux et c'est l'utilisateur qui trinque.
Le plugin produit est a mon sens embryonnaire, il va devoir
évoluer car il y a plein de choses qu'il gère pas, et les
saisies ne sont pas adaptées à tous les cas particulier qu'il va
falloir gérer.
Je suis passé en HTML pour amener une évolution et ouvrir des
portes pour la suite du développement.
2 Les saisies font appel a des morceaux de squelette , qui peuvent ou sont fait pour être surchargés pour les besoins de l'espace public : par exemple intégrer jquery.validate en public pour avoir des validations on the fly (c'est la mode), intégrer un markup spécifique a un framework, bref dans un but d'intégration.
de mon avis introduire dans l'espace privé des Saisies qui sont au départ faites pour faciliter la création de formulaires par le webmestre/intégrateur dans l'espace public, ça n'est pas le top. C'est sur ça que je rejoins l'avis de Cedric. Après quand je vais surcharger le markup d'une saisie faudra que je fasse test_espaceprivé == oui sinon … ce qui n'as pas lieu d'être.
Dire que un array php est plus lisible que du html, c'est votre avis de dev php, moi je trouve pas. un input et son label tiens sur une a deux lignes en saisie si le array doit rester lisible c'est pas le cas. en suite faut scroller pour aller a la fonction traiter, bref faut jouer de la molette, ça fait des fichiers longs (donc pas lisibles) alors qu'un CVT c'est trois fonctions.
Je ne comprend pas bien tes objections
mais les SAISIES sont plus coûteuses que le HTML en CPU pour le
compilateur
et peut être c'est par là qu'elles devraient être améliorées ?
Il y a plusieurs points concernant les saisies mais, de ce que j'ai cru
comprendre, le souci n'est pas à ce niveau :
Le 09/02/2017 à 18:06, Cédric Morin a écrit :
Un formulaire HTML est entièrement malléable, il permet de faire
ce qu'on veut en HTML et de coller aux besoins. Il permet aussi
de maitriser le HTML qui sera rendu.
Ce que pointe Cédric est que le webmestre ou l'intégrateur puisse
adapter à ses besoins et sa charte graphique etc.
Les saisies sont un outil sans doute très pratique pour le
développeur, mais qui forcent à se fondre dans leur moule.
Comme il dit, c'est pratique pour nous, et comme dit MM plus rapide et
plus facile à lire etc. Mais c'est moins flexible pour les webmestres et
ce n'est pas le but recherché.
C'est un choix et je n'aime pas la tournure que ça force à
adopter. Parce qu'on a commencé en SAISIES, quand se présente
le cas complexe qu'elles ne savent pas gérer on a pas le courage
de tout refaire en HTML alors on paresse, on fait un
truc merdouilleux et c'est l'utilisateur qui trinque.
Le plugin produit est a mon sens embryonnaire, il va devoir
évoluer car il y a plein de choses qu'il gère pas, et les
saisies ne sont pas adaptées à tous les cas particulier qu'il va
falloir gérer.
Je suis passé en HTML pour amener une évolution et ouvrir des
portes pour la suite du développement.
2 Les saisies font appel a des morceaux de squelette , qui peuvent ou
sont fait pour être surchargés pour les besoins de l'espace public : par
exemple intégrer jquery.validate en public pour avoir des validations on
the fly (c'est la mode), intégrer un markup spécifique a un framework,
bref dans un but d'intégration.
de mon avis introduire dans l'espace privé des Saisies qui sont au
départ faites pour faciliter la création de formulaires par le
webmestre/intégrateur dans l'espace public, ça n'est pas le top. C'est
sur ça que je rejoins l'avis de Cedric. Après quand je vais surcharger
le markup d'une saisie faudra que je fasse test_espaceprivé == oui sinon
… ce qui n'as pas lieu d'être.
Dire que un array php est plus lisible que du html, c'est votre avis de
dev php, moi je trouve pas. un input et son label tiens sur une a deux
lignes en saisie si le array doit rester lisible c'est pas le cas. en
suite faut scroller pour aller a la fonction traiter, bref faut jouer de
la molette, ça fait des fichiers longs (donc pas lisibles) alors qu'un
CVT c'est trois fonctions.
le pb, dans le cas qui nous concerne, est que le input + le label n'est pas que cela dans le HTML. On a toute les balises SPIP qui alourdissent la lecture
le pb, dans le cas qui nous concerne, est que le input + le label n'est
pas que cela dans le HTML. On a toute les balises SPIP qui alourdissent
la lecture
J'entends bien c'est tout le problème des langages de templating quand on commence a introduire plus de logique et de traitements dans la vue vue que dans le controleur … (éternel débat ^^ )
En fait pour éviter des effets de bords entre privé et public, il faudrait que les surcharges de skel/saisies/ ne s'applique que au public dans l'idée, ou préfixer une saisie de public_input.html
après je sais pas la faisabilité, mais je vois la problématique à l'usage et de ce que j'en ai vu de pars mes expérimentations ou bidouilles appelons ça comme on veut
En fait pour éviter des effets de bords entre privé et public, il
faudrait que les surcharges de skel/saisies/ ne s'applique que au public
dans l'idée, ou préfixer une saisie de public_input.html
après je sais pas la faisabilité, mais je vois la problématique à
l'usage et de ce que j'en ai vu de pars mes expérimentations ou
bidouilles appelons ça comme on veut
j'dis ça j'dis rien > en bon feignant je préfère taper une ligne de css que de réécrire un array de 15km de long