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
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.
j'ai hésite à mettre tout cela dans un autre onglet, plutot qu'une case avec afficher_si
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
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.
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
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
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)
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.
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.
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.
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
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).
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...)
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 :
Reste à faire :
Concrètement dans formidable cela donne ca
Avis bienvenu de @rastapopoulos sur la nomenclatura.
j'ai hésite à mettre tout cela dans un autre onglet, plutot qu'une case avec afficher_si
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.
(et saisies detecterait la verification, et mettrait le bon code js)
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
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
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.
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.
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.
On reprend ce dossier ?
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).
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 :
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...)
b688e2b2bcto3c9b596bff1 year ago