WIP : fixer les de début et de fin de la saisie date #114

Open
maieul wants to merge 1 commits from issue_48 into master
maieul commented 1 year ago
Owner

ping @florence_henry
Pour fixer les dates de début et de fin.
Ne marche que sous SPIP 4, car les attributs data ont changé entre 3.2
et 4.
Permet d'indiquer :

  • soit date fixe
  • un nombre de jour avant/après la date du jour (possibilité de mettre un calcul genre 2*365)

Reste à faire :

  • l'option pour ne pas depasser la date d'un autre champ
  • la vérification de tout cela au niveau de verifier_valeur_acceptable

Concrètement dans formidable cela donne ca

Avis bienvenu de @rastapopoulos sur la nomenclatura.

image

j'ai hésite à mettre tout cela dans un autre onglet, plutot qu'une case avec afficher_si

ping @florence_henry Pour fixer les dates de début et de fin. Ne marche que sous SPIP 4, car les attributs data ont changé entre 3.2 et 4. Permet d'indiquer : - soit date fixe - un nombre de jour avant/après la date du jour (possibilité de mettre un calcul genre 2*365) Reste à faire : - l'option pour ne pas depasser la date d'un autre champ - la vérification de tout cela au niveau de verifier_valeur_acceptable Concrètement dans formidable cela donne ca Avis bienvenu de @rastapopoulos sur la nomenclatura. ![image](/attachments/e936ad19-db11-45ef-9286-721b447ed397) j'ai hésite à mettre tout cela dans un autre onglet, plutot qu'une case avec afficher_si
maieul added 1 commit 1 year ago
0f693ee348 Pour fixer les dates de début et de fin.
Poster
Owner

j'hésite d'ailleurs : j'ai mis cela en option de la saisie, mais ca pourrait très bien être une option de la verification, ce serait même plus logique.

j'hésite d'ailleurs : j'ai mis cela en option de la saisie, mais ca pourrait très bien être une option de la verification, ce serait même plus logique.
Poster
Owner

(et saisies detecterait la verification, et mettrait le bon code js)

(et saisies detecterait la verification, et mettrait le bon code js)
Owner

C'est une bonne question, est-ce que c'est une option de la vérification, et l'interface s'accorde pour ne permettre que ce qui est autorisé. Ou est-ce que c'est une fonction de l'affichage, et la vérif est faite en conséquence. Plutôt la première ? Dans tous les cas faut pas avoir à le faire deux fois.

Sinon je dirais "Jours max dans le passé/futur" plutôt

C'est une bonne question, est-ce que c'est une option de la vérification, et l'interface s'accorde pour ne permettre que ce qui est autorisé. Ou est-ce que c'est une fonction de l'affichage, et la vérif est faite en conséquence. Plutôt la première ? Dans tous les cas faut pas avoir à le faire deux fois. Sinon je dirais "Jours max dans le passé/futur" plutôt
Poster
Owner

Techniquement mettre cela d'abord dans la verif puis dans la saisie qui tient compte de la verif, c'est plus facile car les saisies connaissent leur verif, mais l'inverse non.

Mais

  1. On a le cas du nombre max de caractère, pour textarea, qui n'est pas une verif PHP, mais uniquement JS, alors que cela devrait être la même chose, du coup on peut se demander s'il ne faudrait pas aussi que les verifs connaissent les détails de la saisie (mais ca veut sans doute dire rupture de compat, car on doit reecrire les signatures)
  2. En même temps les verifs sont censés pouvoir s'utiliser en autonome, donc ca n'a pas tellenent de sens, et puis on ferait de la dépendance croisée à ce moment là

Donc j'aurais tendance à dire : deportons cela dans la verif, et pareil pour le nombre max de caractère dans textarea (quitte à maintenir une comptibilité ascendante).

Le seul point que je vois est plus ux : la verif elle est mise dans un onglet un peu caché de la config, alors que là je pouvais mettre ce réglage somme toute relativement important dans l'un des 2 premiers onglets.

Techniquement mettre cela d'abord dans la verif puis dans la saisie qui tient compte de la verif, c'est plus facile car les saisies connaissent leur verif, mais l'inverse non. Mais 1. On a le cas du nombre max de caractère, pour textarea, qui n'est pas une verif PHP, mais uniquement JS, alors que cela devrait être la même chose, du coup on peut se demander s'il ne faudrait pas aussi que les verifs connaissent les détails de la saisie (mais ca veut sans doute dire rupture de compat, car on doit reecrire les signatures) 2. En même temps les verifs sont censés pouvoir s'utiliser en autonome, donc ca n'a pas tellenent de sens, et puis on ferait de la dépendance croisée à ce moment là Donc j'aurais tendance à dire : deportons cela dans la verif, et pareil pour le nombre max de caractère dans textarea (quitte à maintenir une comptibilité ascendante). Le seul point que je vois est plus ux : la verif elle est mise dans un onglet un peu caché de la config, alors que là je pouvais mettre ce réglage somme toute relativement important dans l'un des 2 premiers onglets.
Owner

Mmmh faut pas tout chambouler sur un coup de tête non plus, à réfléchir :)

Notamment ya déjà une vérif "taille" avec un max, mais on peut pas juste transvaser car l'option JS de blocage de la taille (dans l'onglet Affichage je crois) permettait alors dans le même temps d'utiliser une autre vérif (regex ou autre).

Même pour les dates, on pourrait penser que c'est plus de l'UX que juste de la vérif à la fin, par ex quand on sait qu'on demande une date de naissance à des adultes, ya pas à proposer le futur, ni les dernières années. C'est pas tant qu'on veut interdire telles mauvaises valeurs, c'est juste qu'on veut rendre ça pratique quand les gens ouvrent la boite.

Mmmh faut pas tout chambouler sur un coup de tête non plus, à réfléchir :) Notamment ya déjà une vérif "taille" avec un max, mais on peut pas juste transvaser car l'option JS de blocage de la taille (dans l'onglet Affichage je crois) permettait alors *dans le même temps* d'utiliser une autre vérif (regex ou autre). Même pour les dates, on pourrait penser que c'est plus de l'UX que juste de la vérif à la fin, par ex quand on sait qu'on demande une date de naissance à des adultes, ya pas à proposer le futur, ni les dernières années. C'est pas tant qu'on veut interdire telles mauvaises valeurs, c'est juste qu'on veut rendre ça pratique quand les gens ouvrent la boite.
Poster
Owner

oui, mais en même temps il faut aussi que les gens ne puissent pas tricher.

Exemple sur des endroits où il faut un age minimum, faudrit pas que les gens puissent modifier la date et que cela passe. Donc il y a bien une verif après coup.

oui, mais en même temps il faut aussi que les gens ne puissent pas tricher. Exemple sur des endroits où il faut un age minimum, faudrit pas que les gens puissent modifier la date et que cela passe. Donc il y a bien une verif après coup.
Poster
Owner

On reprend ce dossier ?

On reprend ce dossier ?
maieul added 1 commit 8 months ago
b688e2b2bc Pour fixer les dates de début et de fin.
Poster
Owner

Même pour les dates, on pourrait penser que c'est plus de l'UX que juste de la vérif à la fin, par ex quand on sait qu'on demande une date de naissance à des adultes, ya pas à proposer le futur, ni les dernières années. C'est pas tant qu'on veut interdire telles mauvaises valeurs, c'est juste qu'on veut rendre ça pratique quand les gens ouvrent la boite.

Pas d'accord. On peut vouloir interdire les mauvaises valeurs. Par exemple nos formations BAFA: faut s'assurer d'avoir 17 minimum. ALors certes il y aura pas forcément un mauvais plaisantin qui s'amuserai à tricher, mais on sait jamais.

Après c'est aussi à cela que cert verifier_valeur_acceptable : s'assurer que la valeur posté corresponde bien à l'UX du formulaire (pas eu de modifcation DOM en dehors de ce que la personne a saisie).

> Même pour les dates, on pourrait penser que c'est plus de l'UX que juste de la vérif à la fin, par ex quand on sait qu'on demande une date de naissance à des adultes, ya pas à proposer le futur, ni les dernières années. C'est pas tant qu'on veut interdire telles mauvaises valeurs, c'est juste qu'on veut rendre ça pratique quand les gens ouvrent la boite. Pas d'accord. On peut vouloir interdire les mauvaises valeurs. Par exemple nos formations BAFA: faut s'assurer d'avoir 17 minimum. ALors certes il y aura pas forcément un mauvais plaisantin qui s'amuserai à tricher, mais on sait jamais. Après c'est aussi à cela que cert verifier_valeur_acceptable : s'assurer que la valeur posté corresponde bien à l'UX du formulaire (pas eu de modifcation DOM en dehors de ce que la personne a saisie).
Poster
Owner

En réflechissant à ce cas d'usage, les besoins de vérif bafa, il me semble que la situation devient encore plus complexe. En effet pour le cas de la vérif BAFA il pouvoir comparer une différence avec une autre saisie. Donc il faut pouvoir mettre un calcul sous la forme année/jour/minute avec une saisie qui en soit n'est pas une saisie date, mais une radio. Ca pose beaucoup de question d'ergonomie.

Là à chose, je pense à ceci.

Côté saisie date, le constructeur pourrait être :

  • Limiter la portée
  • Si oui afficher :
    • date min fixe (saisie date)
    • date max fixe (saisie date)
    • date min variable (saisie case), si oui afficher :
      • champ à comparer (input ou bien je sais pas si on a une saisie genre "les champs courant du constructeur ?)
      • operateur de comparaison
      • decalage par rapport au champ (case à cocher), si oui afficher :
        • nb jour
        • nb mois
        • nb année
    • date max variable (saisie case), si oui afficher la même chose que pour la min variable

Coté saisie evenement, mettre quelque part (je sais pas) une option pour demander si le point de référence pour la comparaison c'est la date de début ou la date de fin (je crois pour un stage BAFA 1 il faut avoir 17 ans à la fin du stage, mais pour d'autre il faut avoir 18 ans au début du stage...)

En réflechissant à ce cas d'usage, les besoins de vérif bafa, il me semble que la situation devient encore plus complexe. En effet pour le cas de la vérif BAFA il pouvoir comparer une différence avec une autre saisie. Donc il faut pouvoir mettre un calcul sous la forme année/jour/minute avec une saisie qui en soit n'est pas une saisie date, mais une radio. Ca pose beaucoup de question d'ergonomie. Là à chose, je pense à ceci. Côté saisie date, le constructeur pourrait être : - Limiter la portée - Si oui afficher : - date min fixe (saisie date) - date max fixe (saisie date) - date min variable (saisie case), si oui afficher : - champ à comparer (input ou bien je sais pas si on a une saisie genre "les champs courant du constructeur ?) - operateur de comparaison - decalage par rapport au champ (case à cocher), si oui afficher : - nb jour - nb mois - nb année - date max variable (saisie case), si oui afficher la même chose que pour la min variable Coté saisie evenement, mettre quelque part (je sais pas) une option pour demander si le point de référence pour la comparaison c'est la date de début ou la date de fin (je crois pour un stage BAFA 1 il faut avoir 17 ans **à la fin** du stage, mais pour d'autre il faut avoir 18 ans **au début** du stage...)
maieul force-pushed issue_48 from b688e2b2bc to 3c9b596bff 7 months ago
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.