FAQ StrutsConsultez toutes les FAQ

Struts offre deux principaux mécanismes de validation des données saisies dans les formulaires. Par validation, on entend deux choses : bien que les deux systèmes soient à même de faire les deux, on utilise usuellement le plug-in Validator pour les contrôles de surface, puisqu'il ne nécessite pas d'aller-retour entre le client et le serveur, et la méthode validate() des ActionForms pour la validation sémantique.

• Une validation dite de contrôle de surface ou qualitative : il s'agit de vérifier que les données saisies sont bien dans la forme attendue (ex. : une donnée numérique ne contient que des chiffres).
• Une validation sémantique : il s'agit de vérifier que la valeur saisie est bien celle qui est attendue par le système (ex. : un numéro de carte bleue valide).
  

• Le plug-in Validator.
• La méthode validate() des ActionForms.
  

Il faut redéfinir la méthode validate(ActionMapping mapping,HttpServletRequest request) de l'ActionForm et y implémenter les validations. Cette méthode est appelée systématiquement après le remplissage de l'ActionForm.

Si aucune erreur n'est constatée, la méthode retourne null ou une instance de ActionErrors de taille 0.

Si une erreur est constatée, une instance de ActionErrors contenant une ou plusieurs instances de ActionMessage (ActionError pour d'anciennes versions de Struts) est retournée. Les messages d'erreurs sont alors affichés grâce à la balise <html:errors/>.

Pour utiliser le validator, il faut :

• que le plug-in validator soit installé et configuré ;
• que l'ActionForm hérite de ValidatorForm. Cette classe ne nécessite pas d'implémentation des méthodes reset( ) et validate( ) ;
• qu'une règle de validation soit définie dans le fichier xml de validation pour l'ActionForm ;
• que l'attribut validate soit positionné à la valeur true dans le mapping de l'action correspondante.
  

1
2
3
4
5
6
7
8
9
<form-validation> 
   <formset>              
      <form name="logonForm"> 
         <field property="username" depends="required"> 
            <msg name="required" key="error.username"/> 
         </field>    
      </form>         
   </formset>    
</form-validation>

• que la page JSP intègre le tag <html:javascript formName="logonForm"> dans le header ;
• que le formulaire intègre l'appel à la fonction JS générée (par défaut validateNomDuFormulaire) <html:form .... onsubmit="return validateLogonForm(this)">.
  

1
2
3
4
5
6
7
8
9
10
11
12
13
14
errors.required={0} est obligatoire. 
errors.invalid={0} est invalide. 
errors.maxlength={0} ne peut pas avoir plus de 8 caractères. 
errors.minlength={0} ne peut pas avoir moins de {1} caractère. 
errors.range={0} n'est pas dans l'intervalle de {1} à {2}. 
errors.byte={0} doit être un nombre du type byte. 
errors.date={0} incorrecte. 
errors.double={0} doit être un nombre du type double. 
errors.float={0} doit être un nombre du type float. 
errors.integer={0} doit être un nombre du type Integer. 
errors.long={0} doit être un nombre du type long. 
errors.short={0} doit être un nombre du type short. 
errors.creditcard={0} n'est pas un numéro de carte de crédit valide. 
errors.email={0} n'est pas une adresse e-mail valide.

Si on souhaite fournir une validation complémentaire dans un ValidatorForm qui exploite le plugin Validator, il suffit de redéfinir la méthode validate comme suit :

1
2
3
4
5
6
7
8
public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {  
	// ici on récupère tous les messages d'erreurs gérés par le Validator  
	ActionErrors errors = super.validate(mapping, request);  
	if ( ... ) {  
		errors.add("idErreur",new ActionMessage ("cle.erreur"));  
	}  
	return errors;  
}

Par défaut, l'utilisation de la balise <html:javascript> de génération de la fonction JavaScript de validation d'un formulaire génère une fonction dont le nom est lié au nom du formulaire.
Par exemple, <html:javascript name="monForm" /> donnera une fonction validateMonForm.

Il peut être souhaité, pour une raison ou une autre (flexibilité en cas de changement de nom du formulaire, normalisation…) de pouvoir définir soi-même le nom de la fonction générée.
L'attribut method permet cela.

1
2
3
4
5
<html:javascript formName="monForm" method="strutsValidation" /> 
... 
<html:form action="/monAction" onsubmit="return strutsValidation(this);"> 
... 
</html:form>

1
2
3
4
5
6
7
function maValidation(form) { 
	if (...) { 
  
	} 
  
	return strutsValidation(form); 
}

1
2
3
4
5
<html:javascript name="monForm" method="strutsValidation" /> 
... 
<html:form action="/monAction" onsubmit="return maValidation(this);"> 
... 
</html:form>

Il arrive que dans certains cas, il soit plus approprié de procéder à la validation d'un formulaire au niveau d'une classe de type Action.
En effet, dans le cas de classes comme DispatchAction, LookupDispatchAction ou MappingDispatchAction, la déclaration de validation (struts-config) va s'appliquer à toutes les méthodes, ce qui ne sera pas toujours satisfaisant.

L'appel de la validation (pouvant inclure l'utilisation du plugin validator) dans une Action nécessite de travailler avec la classe ActionMessages.
Il est également possible de construire soi-même ses messages (notamment dans le cas d'une vérification nécessitant un appel métier) et de l'ajouter à l'ensemble des messages.

L'exemple ci-dessous montre l'appel de la validation classique par l'intermédiaire de la méthode validate, l'ajout d'un message particulier, l'enregistrement des messages d'erreur, puis la gestion de la navigation.
Ce code a pour prérequis, dans le mapping de l'action, d'avoir positionné l'attribut validate à "false" et d'avoir renseigné l'attribut input.

1
2
3
4
5
6
7
8
9
10
11
12
13
// Validation du formulaire 
ActionMessages errors = form.validate(mapping, request); 
// Appel backoffice 
boolean existeDoublon = monService.rechercherDoublon(form.getNom()); 
if (existeDoublon) { 
    ActionError error = new ActionError("nom.existant"); 
    errors.add("nom", error);  
} 
if ( !errors.isEmpty() ) 
{ 
    this.saveErrors(request, errors); 
    return mapping.getInputForward() ; 
}