Une fonction pour vérifier si une saisie est une date

Bonjour,

Je vous propose un nouvel élément à utiliser : Une fonction pour vérifier si une saisie est une date

les saisies des dates erronées en avez-vous marre? Voici une proposition d'une fonction vérifiant si une date est correcte dans un format donné. Elle est accompagné de javadoc pour plus de détails. Les formats supportés sont yyyy/MM/dd et dd/MM/yyyy

Qu'en pensez-vous ?

Salut,

sympa pour les débutants, mais

- pourquoi parser par une variable intermédiaire s et pas directement st ?
- pourquoi créer une instance de date non utilisée (lignes 14 et 27) ?
- au lieu de tracer dans le System.out en cas de format non supporté, ce serait
mieux de soulever une exception dédiée (UnsupportedFormatException), en particulier pour ceux qui veulent pouvoir traiter en amont que le format est non supporté
- admettons de contraindre à 2 formats supportés (perso je trouve ça vraiment super limité) mais pourquoi contraindre l'utilisateur à les passer en argument : autant fournir une énumération avec 2 valeurs, ou à la limite des constantes !

Pourquoi passer par cette méthode complexe alors que, de toutes façons on va vouloir la parser après -> On aura un DateFormat -> Autant l'utiliser directement.


Le code de la FAQ est plus simple à ce sujet:
http://java.developpez.com/faq/java/...E_DATE_Lenient

Salut,
Merci pour toutes ces remarques aussi constructives qu'elles soient :ccool:. J'ai jugé mieux de mettre à jour la méthode en tenant compte de quelques unes de ces remarques et les points touchés sont les suivants:

Citation:

---

- pourquoi parser par une variable intermédiaire s et pas directement st ?

- pourquoi créer une instance de date non utilisée (lignes 14 et 27) ?

- admettons de contraindre à 2 formats supportés (perso je trouve ça vraiment super limité)

- Le code de la FAQ est plus simple à ce sujet:
http://java.developpez.com/faq/java/...E_DATE_Lenient

---

Néanmoins, ce que je n'ai pas pu réaliser c'est:

Citation:

---

- admettons de contraindre à 2 formats supportés (perso je trouve ça vraiment super limité) mais pourquoi contraindre l'utilisateur à les passer en argument : autant fournir une énumération avec 2 valeurs, ou à la limite des constantes !

---

Si Joel.Drigo serait gentil de m'aider à y parvenir car l'énumération ne prend pas en charge la présentation des formats (yyyy/MM/dd ou dd/MM/yyyy):calim2:

Code:

---

1 2 3 4

public enum format{ yyyy/MM/dd, dd/MM/yyyy }

---

Merci beaucoup

Citation:

---

Envoyé par MasterMbg

Si Joel.Drigo serait gentil de m'aider à y parvenir car l'énumération ne prend pas en charge la présentation des formats (yyyy/MM/dd ou dd/MM/yyyy):calim2:

Code:

---

1 2 3 4

public enum format{ yyyy/MM/dd, dd/MM/yyyy }

---

Merci beaucoup

---

Euh, bah, par exemple

Code:

---

1 2 3

public enum Format { FRANCAIS, ANGLAIS }

---

et un switch dans la méthode pour sélectionner le format associé.

ou :

Code:

---

1 2 3 4 5 6 7

public enum Langue{ FRANCAIS("dd/MM/yyyy"), ANGLAIS("yyyy/MM/dd"); public final String format; private Langue(String format) { this.format=format; } }

---

et dans la méthode ça s'utilise :

Code:

---

1 2 3 4 5

public boolean ver(String st, Langue langue) { ... SimpleDateFormat sdf=new SimpleDateFormat(langue.format); ... }

---

EDIT: au lieu d'une enum, on pourrait également utiliser un argument de type java.util.Locale

Citation:

---

Envoyé par tchize_

Pourquoi passer par cette méthode complexe alors que, de toutes façons on va vouloir la parser après -> On aura un DateFormat -> Autant l'utiliser directement.


Le code de la FAQ est plus simple à ce sujet:
http://java.developpez.com/faq/java/...E_DATE_Lenient

---

C'est vrai dans le cas général, mais on peut avoir des programmes qui ne traitent pas les saisies de date en java.util.Date (un client/serveur ou ce traitement est fait coté serveur uniquement par exemple, un générateur de fichier texte avec des données de type date, etc.) et on veut simplement faire de la validation coté client (c'est vrai que pour valider une saisie dans un formulaire de saisie utilisant un JFormattedTextField ou un composant "date picker" cette fonction est également inutile).

On peut transformer la fonction pour qu'elle renvoit un java.util.Date au lieu d'un booléen aussi.

@joel.drigo
Oui, il y a des cas où on ne passe pas par le parse par la suite. Cependant, en général toutes les dates dans le programmes sont contrainte au même format -> C'est con d'aller créer le DateFormat à chaque fois dans la méthode.
Ce code fait 3 ligne à écrire.

Même si on met ça dans une méthode pour factoriser (ce que je recommande fortement), la méthode sera spécifique à chaque utilisateur -> je trouve ça assez prétentieux d'aller mettre ça dans la section téléchargez de DVP. C'est pas un endroit pour taper tous les bout de code qu'on a écrit sur des coins de table à la pause déjeuner. Après on aurait un truc pour vérifier si c'est un nombre, un autre pour vérifier si c'est positif et un autre pour savoir si mon chat veux du thon ou du poulet aujourd'hui.

Citation:

---

Envoyé par tchize_

Après on aurait un truc pour vérifier si c'est un nombre, un autre pour vérifier si c'est positif et un autre pour savoir si mon chat veux du thon ou du poulet aujourd'hui.

---

C'est déjà le cas :lol: (ici)

J'avoue qu'il y a peu de chance que j'utilise ce type de code, surtout que la plupart des frameworks proposent des vérifications de ce genre intégrées.

Citation:

---

Envoyé par tchize_

@joel.drigo
Oui, il y a des cas où on ne passe pas par le parse par la suite. Cependant, en général toutes les dates dans le programmes sont contrainte au même format -> C'est con d'aller créer le DateFormat à chaque fois dans la méthode.
Ce code fait 3 ligne à écrire.

---

Certes, c'est tout juste un ersatz de tuto pour débutant sans les explications qui vont avec. Y'a un modérateur sur la partie téléchargez je suppose pour faire le tri.

Citation:

---

Même si on met ça dans une méthode pour factoriser (ce que je recommande fortement), la méthode sera spécifique à chaque utilisateur -> je trouve ça assez prétentieux d'aller mettre ça dans la section téléchargez de DVP.

---

Oui, c'est sur.

Citation:

---

Après on aurait un truc pour vérifier si c'est un nombre, un autre pour vérifier si c'est positif et un autre pour savoir si mon chat veux du thon ou du poulet aujourd'hui.

---

Pour le coup, cette dernière méthode pourrait m'intéresser ;) J'aurais à l'écrire que je serais bien ennuyé ;)

Citation:

---

Envoyé par joel.drigo

Pour le coup, cette dernière méthode pourrait m'intéresser ;) J'aurais à l'écrire que je serais bien ennuyé ;)

---

Code:

---

1 2 3 4 5 6 7

public enum Food{ POULET,THON }   public Food whatDoesCatWant(){ throw new SorryException("Désolé, votre dernier chat est mort d'une insuffisance rénale il y a un an et demi"); }

---

J'avoue, mon implémentation ne concerne que mon cas :roll:

Citation:

---

Envoyé par joel.drigo

Pour le coup, cette dernière méthode pourrait m'intéresser ;) J'aurais à l'écrire que je serais bien ennuyé ;)

---

Merci pour avoir jeté un coup d'oeil sur la mise à jour que j'ai faite subir à ma méthode. C'est plutôt encourageant de ta part au lieu de jeter des pierres de feu sur les têtes des développeurs en cours d'expérience (ce qui porrait causer de dégoût de continer).
Encore grand merci, je continuerai dans ce qu'est ma passion.