Le struts validator – framework de validation

Slides:



Advertisements
Présentations similaires
ACTIVE DIRECTORY. Qu'est-ce un service d'annuaire ?: Un service d'annuaire peut être comparé à un agenda téléphonique, celui- ci contient au départ des.
Advertisements

Module 5 : Implémentation de l'impression
JEE 5 - JSF F.Pfister 2 institut eerie Les technologies du web Servlets JSP MVC Model 1 : servlets + JSP MVC Model.
MODIFICATION DES CODES DETERMINES PAR DES TABLE - PROCEDURES 6 septembre 2007 (Joël Martellet, WMO, World Weather Watch, Data Processing and Forecasting.
DTD Sylvain Salvati
FORMATION BE1D Une fois, les identifiants entrés, vous vous retrouvez sur la page daccueil de lapplication. Ce nest quà partir de cette page que vous devez.
INTRODUCTION INTRODUCTION ERGONOMIE Tri par cartes Formulaires Interface Installation Lanceur Documentation TECHNOLOGIES XML + XSL CSS Formulaires génériques.
Module 6 : Gestion et analyse du système DNS
51 Les technologies XML Cours 7 : Utilisations dXML Janvier Version 1.0 -
Design Pattern MVC En PHP5.
Environnement Premier projet.
La configuration Apache 2.2 Lhébergement virtuel.
Projet J2EE Maverick XMLBeans Garcel Jean-Baptiste – Le Loc Martin – Muller Thibaut.
Découvrez notre plate-forme de gestion de listes de diffusion.
Sécurité Informatique
1 ARCHITECTURE DACCÈS la méthode générale modèle de données définitions module daccès / modules métiers construction des modèles les modules daccès, les.
Oct.-2000DESS IIDEE © B. BAH 1 ASP Caractéristiques dun fichier ASP Son extension : « *.asp » La balise: Son indépendance vis à vis de toute plate–forme,
Principes de programmation (suite)
Forum JEE: framework STRUTS 1 et iBATIS
Etude des Technologies du Web services
XML-Family Web Services Description Language W.S.D.L.
JavaBeans Réalise par: EL KHADRAOUY TARIK AOUTIL SAFOWAN.
Struts 1 & 2 Tlohi ibtissam Tabit boutaina Ilias bouras
Sommaire Objectif de Peakup Principes de fonctionnement
Administration de bases de données spatiales avec SavGIS
Auto Exterior Scoop SQP PROCESSUS 24 juillet 2006 Version validée V01.
28 novembre 2012 Grégory Petit
ASP.NET Par: Hugo St-Louis. C ARACTÉRISTIQUES A SP. NET Évolution, successeur plus flexible quASP (Active Server Pages). Pages web dynamiques permettant.
Module 4 : Création et gestion de comptes d'utilisateur
Création et gestion de comptes d'utilisateur
Notions sur le XML Réfs : manuel p 149. Introduction Le XML (eXtensible Markup Language) est un standard d'échange de données. Il fait partie comme le.
Module 8 : Maintenance des logiciels à l'aide des services SUS
Module 2 : Préparation de l'analyse des performances du serveur
Développement dapplication avec base de données Semaine 10 : WCF avec Entité Framework Automne 2013.
Adaptée du cours de Richard Grin
PHP 2° PARTIE : FONCTIONS ET FORMULAIRE
Utilisation avancée.
PHP 5° PARTIE : LES COOKIES
Elabore par BELKADHI ABIR BEN HASSEN SALMA CHEBBI MARWA
XML-schema. Pourquoi XML-schema Les DTD : Pas de typage, peu de contraintes sur les contenus nombre d'apparitions d'un élément à choisir entre 0 et 1.
PROGRAMMATION INFORMATIQUE D’INGÉNIERIE II PRO-1024.
JDBC L'API JDBC est utilisée pour utilisée pour intéragir avec une base de données.
JavaScript.
Algorithmique et programmation (1)‏
PROGRAMMATION INFORMATIQUE D’INGÉNIERIE II
Enterprise Java Beans 3.0 Cours INF Bases de Données Hiver 2005, groupe 10 Stefan MARTINESCU.
PROGRAMMATION INFORMATIQUE D’INGÉNIERIE II PRO-1024.
Tutorat en bio-informatique
Tutorat en bio-informatique Le 14 novembre Au programme… Les objets –Propriétés (attributs) –Constructeurs –Méthodes.
Windows 2003 Server Modification du mode de domaine
Les classes présenté par: RAHMOUNE RIME / ZEKRI SELMA.
S'initier au HTML et aux feuilles de style CSS Cours 5.
FTP : File Transfer Protocol (protocole de transfert de fichier ) est un protocole de communication destiné à l'échange informatique de fichiers sur.
Struts.
PHP 6° PARTIE : LES SESSIONS 1.Introduction 2.Identificateur de session 3.Variables de session 4.Client / Serveur 5.Principe 6.Ouverture de session 7.Enregistrement.
 Formulaires HTML : traiter les entrées utilisateur
eXtensible Markup Language. Généralités sur le XML.
L T I Laboratoire de Téléinformatique 2 Projet de semestre Parseur XML basé sur la DTD : Buts –Utiliser la grammaire définissant un type de fichiers XML.
ASP.NET : Les composants asp dédiés aux données.  Un tableau de données=>Génère du en sortie.  Il permet d’afficher/modifier des données  On peut le.
Comprendre le SGBDR Microsoft Access – partie 2
Les Java Server Pages Dans ce chapitre, nous allons :
CPI/BTS 2 Programmation Web Les sites dynamiques Prog Web CPI/BTS2 – M. Dravet – 02/10/2003 Dernière modification: 02/10/2003.
Introduction à la Programmation Orientée Objet
Guide Acheteur Le site d’achat dédié au monde public
Scénario Les scénarios permettent de modifier la position, taille … des calques au cours du temps. Son fonctionnement est très proche de celui de Macromedia.
DreamWeaver Séance 2 HMIDA Ahmed A2008. Plan 1.Calques 2.CSS 3.Modèles 4.Formulaires 5.Comportements 6.Mise en ligne.
Dreamweaver le retour Avec Les Formulaires Les Calques
DREAMWEAVER MX2 - Séance 2 Les calques Les comportements Les scénarios Les formulaires Les feuilles de style Les modèles Les cadres Mise en ligne Jérôme.
Les bases de données Séance 4 Construction du Modèle Physique (la BDD)
1 Initiation aux bases de données et à la programmation événementielle VBA sous ACCESS Cours N° 4 Support de cours rédigé par Bernard COFFIN Université.
Transcription de la présentation:

Le struts validator – framework de validation Introduction Applications Configuration : le fichier validator-rules.xml Les règles génériques Le fichier validator.xml Le struts validator et l’ActionForm Définition d’une nouvelle règle

Introduction Présentation : Le Validator est à la base un des nombreux projets connexes à Struts, il est maintenant inclus dans la distribution standard depuis la version 1.1. C'est un bon exemple de la dynamique créée autour de Struts.   Ce framework très générique peut être utilisé pour la validation de toute sorte de Java Bean, nous nous contenterons de voir son utilisation à l'intérieur du framework Struts. But : Le but de ce framework est de faciliter la validation des données qui sont transmises à l’application par l’utilisateur. Ces validations se font grâce au Validator de manière déclarative. Le Validator permet des validations côté serveur et client.

Applications Struts permet de faire de la validation à partir des ActionForm. Il faut pour cela: développer une logique de validation pour chaque ActionForm, enregistrer manuellement les erreurs dans des ActionError. Cette technique bien que satisfaisante n'est pas optimisée: il y a de la redondance dans le code (les validations nécessaires à un formulaire sont souvent identiques). il y a des difficultés de maintenance: un changement dans la logique de validation oblige la recompilation du code.  

Applications Le Validator répond à ces problèmes : en déplaçant la logique de validation en dehors des ActionForm. en permettant la configuration déclarative des comportements de validation de chaque ActionForm par le biais d'un fichier XML.   De plus il accélère le développement : en proposant des règles de validation basiques: vérification d'un email, d'un champ obligatoire… en proposant un support pour l'internationalisation: différentes règles de validations peuvent être configurées en fonction du Local de l'utilisateur.

Installation Plusieurs types d'extensions peuvent être ajoutées au framework Struts, le Validator est considéré comme intrusif. En effet l’utilisation du Validator entraîne des modifications dans la manière d’utiliser le framework. Le Validator fait néanmoins partie de la distribution Struts depuis la version 1.1. L’utilisation du Validator impose d’avoir dans le classpath de l’application les packages suivants: commons-validator.jar jakarta-oro.jar : ce package contient les fonctionnalités pour l’utilisation des expressions régulières dans les méthodes de validation.

Installation Les applications Struts qui utilisent le Validator doivent déclarer que le Validator est utilisé. Plusieurs solutions sont envisageables pour cela, nous utiliserons le principe du PlugIn. Le principe du PlugIn sera décrit en détail dans le chapitre sur l’extension du framework Struts. <plug-in className = "org.apache.struts.validator.ValidatorPlugIn"> <set-property property="pathnames" value="/WEB-INF/validator-rules.xml, /WEB-INF/validator.xml"/> </plug-in>

Installation L’utilisation du PlugIn va permettre au chargement de l’application d’initialiser le Validator, l’ensemble des ressources décrivant la logique de validation est alors chargé en mémoire à partir des fichiers de configuration XML. Ces ressources sont spécifiées par les valeurs de l’attribut pathnames qui sont récupérées par l’instance de la classe ValidatorPlugIn.

Configuration Configurer les règles de validations : La configuration utilise deux fichiers xml: le premier permet de décrire les règles de validations utilisées par l'application: validator-rules.xml le second permet d'associer ces règles à un formulaire et à ses champs: validation.xml  

Configuration Le fichier validator-rules.xml : Les règles de validations utilisées dans l'application sont configurées dans le fichier : validator-rules.xml. Ce fichier contient toutes les règles de validation, il est indépendant de l'application et peut donc être réutilisé dans une autre application. Il contient dans la version livrée avec struts un grand nombre de règles configurées. Dans de nombreuses applications les règles proposées suffiront. L'utilisateur garde la possibilité de rajouter ses propres règles, c'est le seul cas ou il modifiera ce fichier. Lorsqu'une règle à vérifier entraîne une erreur, un ActionError est automatiquement créée puis ajoutée dans l'ActionErrors. La suite du traitement est identique à ce que nous avons vu dans la validation au niveau de l'ActionForm. Conseil : Si vous devez ajouter de nouvelles règles il est recommandé de le faire dans un fichier différent, cela facilitera le passage à de nouvelles versions du framework.

Configuration Exemple de fichier validator-rules.xml : name  définit le nom de la règle: ce nom sert à référencer la règle dans ce fichier xml mais également dans le fichier servant à associer les règles aux ActionForm.   classname et méthode  indique la classe et la méthode contenant la logique de validation pour la règle. methodParams  liste des paramètres acceptés par la méthode.

Configuration Exemple de fichier validator-rules.xml (suite) : msg  indique le message renvoyé en cas d'apparition d'une erreur (cf mécanisme d'externalisation des ressources). Par défaut un fichier properties propose des libellés pour chaque type d'erreurs définies par le Validator. depends  cet attribut optionnel permet de spécifier si une règle dépend d'une autre. Ce système permet de créer des relations de hiérarchie sur les règles; Si B est dépendant de A alors le Validator vérifie d'abord A, en cas d'échec une erreur sur la règle A est renvoyée, en cas de succès, la règle B est vérifiée.

Règles génériques du validator Les règles génériques : Un certain nombre de règles sont définies par le framework Validator, ces règles sont très basiques, il faut les considérer comme des règles atomiques qui serviront à l’élaboration de règles plus complexes. Ces règles sont définies dans la classe org.apache.commons.validator.GenericValidator.

Règles génériques du validator Les règles génériques pour Struts : Afin de faciliter l’utilisation des règles dans le framework Struts, une classe utilitaire a été ajoutée. Cette classe définit des règles de niveau supérieur qui sont couplées au framework Struts, mais qui facilitent l’utilisation du Validator avec Struts. Ces règles sont définies dans la classe : org.apache.struts.util.StrutsValidator. Cette classe contient la logique de validation utilisée par Struts, elle contient les méthodes qui sont déclarées par le validator-rules.xml. Quand une de ces méthodes est invoquée, si la validation échoue, un objet ActionError est automatiquement créé et ajouté à l’objet ActionErrors. Ces erreurs sont ensuite stockées pour pouvoir être retrouvées et utilisées par la vue.

Le fichier validation.xml Présentation :   Ce fichier permet de faire correspondre une règle déclarée dans validator-rules.xml avec un ActionForm. C'est à ce niveau qu'intervient la notion de configuration déclarative, le code n'est pas définit au niveau de l'ActionForm. Principe : Le principe est de déclarer dans des balises <form> la logique de validation pour un formulaire. L’attribut name de cette balise permet de spécifier le formulaire concerné. Des sous-balises <field> permettent de spécifier les règles associées à un champ du formulaire.

Le fichier validation.xml Les attributs de la balise <field> : Attribut Description property La propriété du formulaire associée à cette règle. depends Indique une ou plusieurs règles à utiliser pour la propriété. indexedListProperty Indique une propriété dans l’ActionForm qui retourne une Collection qui peut être indexée.

nom des règles de validation Le fichier validation.xml Exemple : nom du formulaire nom du champ nom des règles de validation valeur à rechercher dans le fichier « .properties » et à passer en argument <form name="formEnregistrement"> <field property="nom" depends="required,maxlength"> <arg key="error.nom" position="0"/> <arg name="maxlength" key="${var:maxlength}" resource="false" position="1"/> <var> <var-name>maxlength</var-name> <var-value>20</var-value> </var> </field> </form> argument passé aux 2 règles argument passé à la règle « maxlength » indique que la valeur n’est pas à rechercher dans le fichier « .properties »

Le fichier validation.xml Exemple de fichier « .properties » : IMPORTANT : -La règle « required » appel le message « errors.required » en cas d’erreur en lui passant des paramètres. La règle « maxlength » appel le message « errors.maxlength » en cas d’erreur en lui passanr des paramètres. Ces messages sont les suivants : Ce qui donnera en cas d’erreur : error.nom=Le nom errors.required={0} est obligatoire errors.maxlength={0} doit posséder moins de {1} caractères Le nom est obligatoire Le nom doit posséder moins de 20 caractères

Le struts Validator et l’ActionForm Utilisation d'un ActionForm : Comme nous l'avons vu, le Validator a un comportement intrusif dans le Framework, l'utilisation d'un ActionForm ou DynaActionForm n'est pas directement possible. Il faut utiliser des classes définies par le framework Validator. Ces classes héritent des classes du framework Struts, la logique d’utilisation de ces classes reste donc identique.   Deux classes peuvent être utilisées: ValidatorForm ValidatorActionForm La classe ValidatorForm permet d’utiliser la validation sur un ActionForm comme nous l’avons décrite précédemment. La classe ValidatorActionForm permet de lier les règles non pas à un formulaire, mais à une Action, un formulaire peut alors avoir plusieurs systèmes de validation en fonction de la règle qu’il appelle.

Définition d’une nouvelle règle Procédé : Si l'ensemble des règles définies par le Validator n'est pas suffisant pour l'application, il reste possible d'en rajouter. Il faut pour cela suivre trois étapes: définir une classe avec la méthode de validation. Implémenter la méthode de validation. Lier la règle à un formulaire.