Remonter un message d'erreur lors de la saisie d'une date erronée

Remonter un message d'erreur lors de la saisie d'une date erronée
0
Tags: #<Tag:0x00007f768e96a378>

Je souhaite obtenir une erreur m’informant que la valeur saisie est incorrecte lorsque je saisis manuellement (sans utiliser le calendrier) une valeur supérieure à 12 (mois) ou supérieure à 31 (jours) dans le champ “Date”.

De plus j’ai remarqué que cette valeur incorrecte remonte à ‘01’ côté Back ce qui ne me permet pas de valider la date avant la création de l’objet.

Le même problème sur le jour avec des valeurs supérieur à 31.

Il faudrait effectivement une validation de date/time plus solide à la fois coté client (en contrôle de surface) et coté client (en vraie validation bloquante).

Ce n’est clairement pas à vous de le faire spécifiquement. Je passe votre post en “feature request”

Merci @David pour votre réponse, et tenez-moi au courant dès que le besoin est mis en place.

Auparavant le date-picker validait/formatait la date à chaque change (ou blur je ne sais plus), en essayant de trouver une date valide “proche” de celle saisie.

Nous avons dû retirer ce fonctionnement car la date proposée était en général inadaptée (genre en 1900), et on avait aussi besoin de pouvoir saisir “is null” dans un filtre de date sur une évolution récente.

Du coup le contrôle de surface a effectivement sauté, on va en remettre un en front.
Par contre en back, il y a toujours eu un contrôle de date valide en java via Calendar, on va vérifier qu’elle n’a pas non plus disparue (au pire c’est la base qui rejette la date…).

On a aussi un autre problème avec les dates en rendering “Mois” lors du save. Si on saisie “2020-03” et après “save” ça affiche n’importe quoi.

En regardant l’historique de ce besoin, il apparaît qu’en terme d’UX, il faut éviter les erreurs utilisateur.
Bref il n’y a jamais de date fausse envoyée par la UI (sauf à pirater le flux ajax sortant).

Si une date est fausse à l’écran, la logique est depuis des années que la UI la corrige avant de l’envoyer au serveur en reformattant au pire la date en (année sur 4)-(mois entre 01 et 12)-01.

PS: tous les date-pickers font cela.Il est préférable de guider l’utilisateur que de le gronder en lui laissant la main de saisir des erreurs.

.

Ca n’empêche pas que de toute façon une date incorrecte (genre 2020-22-22) doit être rejetée en contrôle bloquant coté serveur (ne serait-ce que pour les cas d’import XML/CSV/… et/ou les appels de services où il n’y a pas une UI pour aider). Je ne sais plus trop ce que l’on fait exactement à ce niveau.

Le back est bien méchant et ne laisse rien passer !
Et au pire la base de données non plus.