Logo JavaScript

Moteur de validation de données

Publié le 4 décembre 2012 par (7 commentaires)
Flattr this!

Salut à tous, je viens vers vous pour m'enquérir de votre avis. Petits et grands, expérimentés ou non, j'aimerais savoir ce que vous pensez de ma dernière création.

Pour divers besoins, j'ai dû créer mon propre validateur de données. Bon je sais vous allez me dire que j'ai réinventé la roue mais les trucs existants ne me convenaient pas. Et c'est toujours plus amusant de refaire soi même les choses pour les comprendre.

Du coup, j'ai créé un gist (https://gist.github.com/4148467) et j'aimerais bien votre avis.

Le validateur ValEngine fonctionne aussi bien en synchrone qu'asynchrone et est même totalement ouvert d'esprit à ce sujet puisqu'il peut même tolérer de travailler avec les deux types dans un même set de contrôles.

Le principe est d'avoir de vôtre côté un jeu de données à valider (un tableau par exemple). Vous indiquer à ValEngine quel tableau et quel est l'index (pour permettre à ValEngine de s'y retrouver), les méthodes de contrôles à appliquer sans vous soucier qu'elles soient synchrones ou non.

Pour le moment vous pouvez seulement vérifier qu'une donnée est bien existante (required), une adresse mail (is_email), une adresse URL (is_url), une chaîne de caractères ne contenant que des lettres (is_alpha_string) ou si c'est un nombre, entier ou non (is_numeric).

Précision à propos de is_email, même si le format est correct, il peut arriver que le domaine indiqué soit erroné. J'ai donc intégré une version personnalisée du validateur de mails de Kicksend embarquant les domaines de mails les plus courants en France, Angleterre, aux USA et en Allemagne (ce n'est pas la seule personnalisation). Ainsi si le format est correct mais que la fonction pense qu'il y a erreur, elle vous proposera vient l'objet JSON de résultat (méthode non-intrusive) un domaine plus approprié. Par exemple, si vous écrivez toto@gmil.com, la fonction vous dira que c'est ok, mais qu'elle pense que vous vouliez écrire toto@gmail.com.

Qu'en dites-vous ? Merci d'avance pour vos avis !

Rappel de l'adresse du gist https://gist.github.com/4148467

Flattr this!

A propos de Mathieu

Ingénieur développeur web dans la vente par correspondance B2B, adepte de nouvelles technologies et d'innovation. Vous pouvez aussi me retrouver sur Twitter @mathrobin
Cette entrée a été publiée dans JavaScript, avec comme mot(s)-clef(s) , . Vous pouvez la mettre en favoris avec ce permalien.
  • Savageman

    Hello,
    Voici un retour « visuel ».
    À titre personnel, je n’aime pas l’API. Devoir repasser les data pour ajouter chaque règle c’est un peu contraignant…

    Sinon tu appelles plusieurs fois « validStore » pour chaque clé de data lorsque tu as plusieurs règles de validation (une fois pour required, une fois pour email).
    Je ne suis pas certain de bien comprendre, doit-on appeler autant de fois la fonction qu’on a mis de règles ? L’exemple n’est pas super clair.

    Après je n’ai peut-être tout simplement pas compris la philosophie de la classe, mais dans ce cas, c’est que c’est mal expliqué :-)

    Voici un exemple de ce que je considèrerai plus satisfaisant : http://snipr.it/~sK

    • http://www.mathieurobin.com/ Mathieu

      Salut et merci pour ce premier retour.

      Effectivement, je réfléchis aussi à la possibilité d’assigner plusieurs règles d’un coup. Ça ça sera pas très compliqué.
      Quand à l’exemple, effectivement, il n’est pas hyper clair. Tu peux appeler une seule fois validStore pour x règles concernées. Là c’est une doc de démo, quand je créerais un vrai dépôt GitHub pour le projet, je referais ça bien propre.

      Dans ton exemple d’usage, tu assignes une/des règle(s) à une clé et ensuite tu demandes de vérifier sur tel objet avec la clé concernée ? Pourquoi pas, c’est pas idiot, après tout pour assigner une règle, on n’a pas besoin de connaitre la donnée…

      Après il est effectivement aussi prévu que je distingue la possibilité de valider un champ ou tout un storage. Pour le cas du storage, j’envisage de retourner un objet enrichi avec le statut global et un tableau contenant le statut de validation pour chaque champ.

      Je te remercie de ton retour, ça sera bénéfique :)

  • http://forresst.github.com forresst

    Salut Mathieu,
    Je suis d’accord avec Savageman, quelle est exactement la philosophie ?
    Souvent la validation des donnés ce fait via un submit de formulaire et il est rare qu’un formulaire ne contienne qu’un champs. Il faut donc tester toutes les règles de validation de tous les champs et pour chaque champs afficher les erreurs (ou arrêter les tests dès qu’une erreur de validation se produit et par exemple se positionner sur le premier champs qui est en erreur).
    Pourrais tu donner un exemple selon les scénarios proposés ci-dessus, cela permettrait peut être de mieux comprendre son utilisation et de ce fait, améliorer le retour de la fonction.

    En tout cas, j’aime bien ton idée de faire partager ton code dans le but de l’améliorer.
    A+

    • http://www.mathieurobin.com/ Mathieu

      Je milite dans ma boite pour qu’on ouvre un max de code. Pas tout mais au moins les composants qui peuvent répondre à une problématique reconnue et souvent cas d’école.

      Ce validateur doit répondre à certains critères :
      – pouvoir valider un champ (ok) ou tous (à venir) ;
      – pouvoir accepter d’autres règles personnalisées (à venir) ;
      – être léger (< 10 Ko) ; – être portable (IE 6+, Firefox 3+, Chrome, Safari, Opera 8+, Android 2+, iOS 3+ et aussi sous nodeJS) ; – doit proposer les domaines de mails approchants ; – accepter des validations synchrones et asynchrones ; – pouvoir travailler avec les deux dans le même cycle de validation, que ce soit champ ou tout le jeu de données ; – être indépendant d’une question de formulaire. Je précise le dernier point : pour pouvoir travailler avec nodeJS sans aspect « visuel », on a décidé que le validateur devait être indépendant de la notion de formulaire. C’est à dire qu’avant de pouvoir valider un formulaire, il faudra en collecter les données. serializeArray de jQuery fait ça très bien par exemple. Autre exigence personnelle, du coté de la qualité de code, j’ai réduit au maximum les tolérances de JSLint.

  • Nico

    Don’t forget default value!
    Ca ne parait pas logique vu l’usage, mais – on ne sait jamais -, si l’user oublie les callbacks a la rigueur throw une belle exception pour lui dire de les implémenter!

    • http://www.mathieurobin.com/ Mathieu

      Tu n’as pas tort, mais ça sera du trow exception. Je ne veux pas surcharger le truc et que les utilisateurs se reposent sur la facilité. Ou sur un comportement qu’ils pensent valables. En tout cas la remarque est bonne. Merci

  • Nico

    Correction, tu as zappé toutes les default_values :)

Articles liés