Semana 02 Validaciones

Struts 2

Validaciones

Curso: Desarrollo de Aplicaciones Web II

Equipo de Profesores del Curso

Objetivos

Aprender a validar los formularios de

manera manual en Struts 2.

Aprender a utilizar los validadores que

vienen incorporados dentro de Struts 2

mediante XML.

Aprender a crear “Custom Validators”

Validación Manual

La clase ActionSupport implementa 2 interfaces:

Validateable

ValidationAware

El método validate() se ejecutará durante el flujo por

defecto en el framework. Es decir, se ejecuta ANTES del

método execute().

El método devuelve un resultName “input” si ocurre

alguna falla en la validación.

Si el resultado con name=“input” no está presente en

el archivo de configuración, se genera un error.

LAB # 0

No olvidar Getter/setter

Este método se ejecuta primero

Validación por XML

Se requieren 3 pasos:

1) Determinar sobre que Action se realizarán las

validaciones. Por ejemplo el Action Class se llama Abc.java

2) Escribir el archivo de configuración para la validación. El

archivo sigue el formato:

ActionClassName-validation.xml

En el ejemplo sería: Abc-validation.xml

3) Definir a donde se envía la respuesta en caso la

validación falle. Para ello se registra el result “input” en el

archivo de configuración de struts.

<result name="input"> …. </result>

Esquema típico del archivo XML

Definición DTD

Root Element

Field validators

Plain (non-field validators )

validators

LAB # 1 : required

Verifica que el valor del campo no sea NULL.

Nota: Un string vacío no es NULL.

Observar que el

campo esta comentado

Lab #2 : requiredstringVerifica que el valor del campo no sea NULL y que tampoco sea

vacío.

Parámetro “trim” ( valor por defecto “true” )

Lab #3: stringlengthVerifica la longitud de un campo No vacío.

Parámetros “trim” , “minLenght”, “maxLength”

Lab #4: intVerifica que el valor del campo pueda convertirse a “int”

Parámetros “min”, “max”. Si están presentes, verifica que el valor

esté dentro del rango

Lab #5: dateVerifica que el valor del campo esté dentro del rango de fechas.

El formato a emplearse depende del LOCALE

Parámetros “min”, “max”. Si están presentes, verifica que el valor

esté dentro del rango

Lab #6: emailVerifica que el valor del campo sea un formato de correo

electrónico.

Usa expresiones regulares (regexpr) con el formato siguiente:

Lab #7: urlVerifica que el valor del campo sea un formato de URL

Trata de crear un objeto java.net.URL usando el valor del campo.

Si no ocurre una excepción durante la creación del objeto, la

validación es OK.

Ejemplos: http / https / ftp /file

Un validator debe implementar la interface Validator que

es parte del paquete com.opensymphony.xwork2.validator

El interceptor “Validatior” es el responsable de cargar y

ejecutar los validadores.

El interceptor invoca al metodo “validate” pasandole el

objeto a ser validado. Dicho método es el que debe sobre

escribirse cuando se diseña un custom validator.

Antes que implementar la Interface Validator, es más

conveniente extender las clases:

ValidatorSupport si se diseña un “plain validador”

FieldValidatorSupport si se diseña un “field validator”

Custom Validators

Lab #8: Custom Validators

En una sola línea

…

Los validators por defecto están registrados en el archivo

xwork.jar en la ruta siguiente:

Los customs validators debe ser registrados:

Registro de Custom Validators

Expresiones Regulares

Validador “regex” : verifica que el valor de un campo

coincida con un patrón de “expresión regular”.

Los validadores “expression” y “fieldexpression” se

usan para validar un campo contra una expresión OGNL.

Un error en el validador “expression” genera un action

error.

Un error en el validador “fieldexpression” genera un

field error.

Lab #9: regex Validators

http://struts.apache.org/2.2.1.1/docs/form-validation.html

http://struts.apache.org/2.2.1.1/docs/validation.html

Referencias

Investigar el “conversion” validador

Practicar los custom validators

Revisar los patrones de java.lang.regex.Pattern