Entregas Anteriores
- Conociendo struts 2 Introducción y preparación de herramientas
- Conociendo struts 2 - Armando mi primer Proyecto.
- Conociendo struts 2 - Proyecto de estudio.- Generando el Login
puede acceder al codigo fuente de la ultima entrega desde struts2_proyecto_login.zip
Acción Struts 2 se basa en un marco de validación proporcionada por XWork para permitir la aplicación de las reglas de validación de entrada a sus acciones antes de que se ejecuten, esto nos permite separar la lógica de validación de real Java del codigo JSP, donde se pueden revisar y modificar fácilmente más tarde.
Struts 2 viene con un conjunto de rutinas útiles para manejar la validación de formularios de forma automática y se puede manejar tanto del lado del servidor y cliente la validación de formularios. Si por supuesto estas rutinas no cumplen con nuestra necesidad la flexibilidad del framework permite crear su propia lógica de validación mediante la interface
com.opensymphony.xwork2.Validator permitiendo definir elemento reutilizables para otros proyectos que abordemos en el futuro.Validator utiliza archivos de configuración XML para determinar qué rutinas de validación debe ser instalado y cómo deben ser aplicados para una aplicación dada. si el archivo validators.xml no esta presente en el classpath, un archivo de validación por defecto es tomado desde
com/opensymphony/xwork2/validator/validators/default.xml.El primer archivo de configuración validador-rules.xml, declara las rutinas de validación que debe estar en el framework y proporciona la lógica para cada una de las validaciones. El archivo validador-rules.xml también define el código de cliente JavaScript para cada rutina de validación.
Validador puede ser configurado para enviar el código JavaScript en el explorador de manera que la validación se realiza en el lado cliente, así como en el lado servidor.
El tipos de validación de abordaremos esta asociado a campos, si bien existen otros asociados a expresiones de contexto no las tocaremos por le momento.
- Field Validators : trabaja sobre campos accesibles por un action, existen validaciones que se pueden realizar en un conjunto de campos trabajando en la accion por completo pero es una opción no tan recomendada, ya que los mensajes de validación de campo están vinculados al campo relacionado y será presentado junto al elemento de entrada correspondiente en la vista.
<validators> <field name="bar"> <field-validator type="required"> <message>You must enter a value for bar.</message> </field-validator> </field> </validators>
Ahora para continuar con el proyecto de estudio agregaremos un nuevo formulario que simule la alta de usuarios en la aplicación, hablamos de simular por que realmente por el momento no estamos persistiendo los datos en ninguna base de dato o archivo.
Que es lo que vamos a hacer:
Input: desde luego ingresaremos los datos en un formulario que llamaremos Usuarios_Alta.jsp que es donde definiremos el formulario para el ingreso de datos.
Logica: Crearemos un action llamado UsuarioAction.java que por supuesto sera un POJO y el metodo de ejecucion que gestiona el retorno a la vista.
Output: Desde luego el retorno se realizara a la vista con un jsp llamado Usuarios_op_exitosa.jsp.
ahora esta sera la estructura de nuestro proyecto
UsuarioAction.java: action que contrendra la logica del alta de usuarios.
AplicationResources.properties: archivo de recurso de etiquetas consumidas por la aplicación.
struts.xml: archivo de configuración de struts que se encuentra en el directorio de recursos para que pueda mapear los recurso con las capas de la aplicación.
Login.jsp: formulario de login
Welcome.jsp: pagina de retorno del login donde solo presentamos un saludo.
Usuarios_Alta.jsp: formulario de alta de usuario.
Usuarios_op_exitosa.jsp pagina de respuesta de la operacion.
UsuarioAction.java En esta oportunidad no perderemos tiempo enseñando como generar los get y set de las propiedades desde eclipse por que ya lo mostramos en entregas anteriores.
package actions;
import com.opensymphony.xwork2.ActionSupport;
public class UsuarioAction extends ActionSupport {
private String nombre;
private Integer edad;
private String Email;
private String Telefono;
public String Alta_Usuario() {
return SUCCESS;
}
public String getNombre() {
return nombre;
}
public void setNombre(String nombre) {
this.nombre = nombre;
}
public Integer getEdad() {
return edad;
}
public void setEdad(Integer edad) {
this.edad = edad;
}
public String getEmail() {
return Email;
}
public void setEmail(String email) {
Email = email;
}
public String getTelefono() {
return Telefono;
}
public void setTelefono(String telefono) {
Telefono = telefono;
}
}
Nota: Podemos observar que es una clase que extiende de com.opensymphony.xwork2.ActionSupport con las virtudes que ya mencionamos en entregas anteriores y que por supuesto es una clase con propiedades y un método que representa la acción que indica el retorno según la operación. En esta oportunidad no lleva el nombre execute sino un nombre que define la acción llamado Alta_Usuario.
Pero podemos observar la presencia de las siguientes propiedades
- private String nombre;
- private Integer edad;
- private String Email;
- private String Telefono;
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE struts PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"
"http://struts.apache.org/dtds/struts-2.0.dtd">
<struts>
<constant name="struts.enable.DynamicMethodInvocation"
value="false" />
<constant name="struts.devMode" value="false" />
<constant name="struts.custom.i18n.resources"
value="ApplicationResources" />
<package name="default" extends="struts-default">
<action name="login"
class="actions.Login">
<result name="success">Welcome.jsp</result>
<result name="error">login.jsp</result>
</action>
<action name="usuario"
class="actions.UsuarioAction">
<result name="success">Usuarios_op_exitosa.jsp</result>
<result name="input">Usuarios_Alta.jsp</result>
</action>
</package>
</struts>
Nota: Analicemos la nueva declaración podremos ver las declaración de constantes para la lectura de recurso de propiedades, la definición del action para el login y el nuevo código agregado.
<action name="usuario" class="actions.UsuarioAction"> <result name="success">Usuarios_op_exitosa.jsp</result> <result name="input">Usuarios_Alta.jsp</result></action>
Pero si tenemos algo nuevo cada vez que la lógica de validación encontrar algún error de validación, se redirige a la página de usuario especificada como entrada.
ApplicationResources.properties: en el archivo de recursos deberemos agregar los label que utilizaremos para las vistas y la respuesta a validaciones que luego veremos como implementar.
label.username= Username
label.password= Password
label.login= Login
label.nombre= Nombre
label.edad= Edad
label.email= Email
label.telefono= Telefono
label.agregar.usuario=Agregar Usuario
errors.invalid=${getText(fieldName)} is invalid.
errors.required=${getText(fieldName)} is required.
errors.number=${getText(fieldName)} must be a number.
errors.range=${getText(fieldName)} is not in the range ${min} and ${max}.
Usuarios_Alta.jsp: es solo la pagina de ingreso de datos para la funcionalidad de alta de usuario.
<%@ page contentType="text/html; charset=UTF-8"%>
<%@ taglib prefix="s" uri="/struts-tags"%>
<html>
<head>
<title>Usuarios Form - Struts2 Proyecto de Estudio | </title>
</head>
<body>
<h2>Usuarios Form</h2>
<s:form action="usuario.action" method="post">
<s:textfield name="nombre" key="label.nombre" size="20" />
<s:textfield name="edad" key="label.edad" size="20" />
<s:textfield name="Email" key="label.email" size="20" />
<s:textfield name="telefono" key="label.telefono" size="20" />
<s:submit method="Alta_Usuario" key="label.agregar.usuario" align="center" />
</s:form>
</body>
</html>
Ahora cuenta con los elementos textfield que hace referencia a los campos del formulario donde podemos notar lo siguiente la relación que existe en su utilización con las propiedades definidas en el action y los label definidos en el archivo de recursos.
Otro punto a destacar es el boton y la relacion que existe con el metodo del action y el label definido para tal fin en el archivo de recursos.
Usuarios_op_exitosa.jsp: es solo un JSP con un mensaje de operación exitosa.
<%@ page contentType="text/html; charset=UTF-8"%>
<%@ taglib prefix="s" uri="/struts-tags"%>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Insert title here</title>
</head>
<body>
<h2>Usuario agregado de manera exitosa.</h2>
</body>
</html>
Welcome.jsp: esta es la pagina que llegamos luego del login solo presenta una modificación y es un solo link a la pagina de alta.
<%@ page contentType="text/html; charset=UTF-8"%>
<%@ taglib prefix="s" uri="/struts-tags"%>
<html>
<head>
<title>Welcome</title>
</head>
<body>
<h2>Hola, <s:property value="usuario" />...!</h2>
<s:a href="Usuarios_Alta.jsp">Agregar Usuario</s:a>
</body>
</html>
Bueno si ejecutamos el proyecto vamos a obtener un circuito funcional como el siguiente
En primera instancia la pantalla login que ya conocíamos de entregas anteriores.
Cuando ingreso diego\herrera y realizo el login con exito me lleva a la siguiente pantalla donde tengo un saludo y un link al formulario de alta de usuarios.
Ahora llegaríamos a la pantalla de alta de usuarios.
Donde ingresaríamos los datos al formulario.
El resultado final seria una pagina de retorno con éxito
Ahora todo muy lindo bonito y barato por el momento pero no agregamos las validaciones necesarias por el momento a nuestro formulario.
Las reglas de validación que vamos a definir son las siguientes:
- En primera instancia todo los campos son requeridos para la ejecución de la acción.
- Validaremos que la edad este entre 1 y 100.
- Que la dirección de email sea valida.
Ahora lo que hacemos es generar en el mismo directorio de la clase action un archivo que lo llamaremos nombreclaseaction-validacion.xml, para nuestro ejemplo es claro que se llamara.
Que tendrá el siguiente código con las reglas de validación.
<!DOCTYPE validators PUBLIC "-//Apache Struts//XWork Validator 1.0.3//EN"
"http://struts.apache.org/dtds/xwork-validator-1.0.3.dtd">
<validators>
<field name="nombre">
<field-validator type="requiredstring">
<param name="trim">true</param>
<message key="errors.required" />
</field-validator>
</field>
<field name="edad">
<field-validator type="required">
<message key="errors.required" />
</field-validator>
<field-validator type="int">
<param name="min">1</param>
<param name="max">100</param>
<message key="errors.range"/>
</field-validator>
</field>
<field name="Email">
<field-validator type="requiredstring">
<message key="errors.required" />
</field-validator>
<field-validator type="email">
<message key="errors.invalid" />
</field-validator>
</field>
<field name="telefono">
<field-validator type="requiredstring">
<message key="errors.required" />
</field-validator>
</field>
</validators>
El resultado de validación en la pantalla de alta de usuario tendría resultados como
Nota: ahora todas estas validaciones se están realizando del lado servidor y podemos notar la correspondencia de la respuesta a la acción en base a los label definidos en el archivo de recursos.
.Creo que hay validaciones definidas por el usuario y validaciones de lado cliente que no se abordaron en esta entrega pero creo que cuentan con el conocimiento para un paso mas con la ayuda de internet.
Este es el código fuente del capitulo.
Saludos
No hay comentarios:
Publicar un comentario