Aplicaciones web con jakarta struts - Javier Oliver Fulguera

Aplicaciones Web con
Jakarta Struts
Javier Oliver Fulguera


@javioliful

www.oliverfulguera.es

Tema 1: Introducción y arquitectura
l  Tabla de contenidos
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 

Introducción
Modelos arquitectónicos
Arquitectura MVC
El Controlador (Controller)
El Modelo (Model)
La Vista (View)
¿Qué es un Framework?
Framework Jakarta-Struts
Alternativas a Struts
Barracuda MVC
Cocoon
Expreso
Freemarker, Velocity y Web Macro
Maverick
Spring
Java Server Faces
Instalando Struts


@javioliful


Introducción
l  El framework (marco de trabajo) open source Struts se creó para permitir
que los desarrolladores pudieran crear aplicaciones Web basadas en
componentes web desarrollados con tecnología Java (Servlets y Java
Server Pages). Al igual que ocurre con cualquier construcción, una
aplicación debe asentarse sobre unos pilares que permitan crecer al resto
de la estructura. La traducción al castellano de la palabra Strut define muy
bien el propósito del proyecto, ya que actuaría como un puntal (pilar) sobre
el que se soporta el peso del resto del desarrollo.
l  El framework fue creado por Craig R. McCIanahan y donado a la Apache
Fundation Software (ASF) en el año 2000, convirtiéndose poco después en
una referencia para los desarrolladores de aplicaciones web.


@javioliful


Modelos arquitectónicos
l  Modelo 2 -> Este modelo se apoya en el patrón de diseño Model-ViewController, utilizando JavaBeans-JSPs-ServIets. Los javabeans
representan al modelo de la aplicación, las páginas JSP a la vista, y los
servlets actúan como controladores.
l  MVC es tan común que se han desarrollado varias infraestructuras en torno
a este patrón de diseño, entre ellas Apache Struts y Java Server Faces


@javioliful


Arquitectura MVC
l  El Controlador (Controller)
¡  En este modelo un servlet central recibe las peticiones del cliente, procesa la
URL recibida y delega el procesamiento de la lógica de la aplicación a los
distintos JavaBeans. Estos generan un resultado que el servlet guarda en el
contexto de la petición, la sesión o la aplicación. En un último paso, el servlet
transfiere el control a un JSP que lleva a cabo la presentación de los resultados.

l  El Modelo (Model)
¡  El modelo es el que maneja los datos y la funcionalidad de la aplicación. Los
JavaBeans (o EJBs para aplicaciones más escalables) desempeñan el rol de
modelo. En este papel, pueden ejecutar lógica de negocio o bien guardar datos.
¡  Normalmente, el servlet controlador invoca un método en el bean lógico y éste
devuelve un bean de datos al que tiene acceso el diseñador de la página JSP.

l  La Vista (View)
¡  Este papel es ejecutado por páginas JSPs. El servlet controlador transfiere el
control al JSP después de haber guardado en un contexto el resultado en forma
de un bean de datos. JSP usa las acciones jsp:useBean y jsp:getProperty
para recuperar datos y formatear la respuesta en HTML o XML.

@javioliful


Arquitectura MVC (II)


@javioliful


¿Qué es un Framework?
l  Es un conjunto de clases e interfaces que cooperan para solucionar un tipo
específico de problema software.
l  Tiene las siguientes características:
¡  Consta de múltiples clases o componentes, cada uno de los cuales
puede proporcionar una abstracción de algún concepto determinado.
¡  Define cómo estas abstracciones trabajan conjuntamente para solucionar
un problema.
¡  Sus componentes son reutilizables.
¡  Organiza patrones en un nivel superior.

l  Un framework, además, debería proporcionar un comportamiento común a
múltiples aplicaciones.


@javioliful


l  Struts es una de estos frameworks basadas en MVC. Provee un conjunto de clases
y taglibs (librerías de etiquetas personalizadas) que conforman el controlador, la
integración con el modelo (o lógica de negocio) y facilitan la construcción de vistas.
l  Las aplicaciones basadas en Struts constan de:
¡  Código Java
¡  Descriptores de despliegue (deployment descriptors) que configuran el framework para el
uso de nuestra aplicación
¡  Struts nos proporciona una serie de elementos para la construcción de aplicaciones web:
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 


Un servlet (ActionServIet) que actúa como controlador MVC totalmente configurable.
Clases base que son extendidas para implementar la lógica de la aplicación web:
org.apache.struts.action.Action
org.apache.struts.action.ActionForm
Un conjunto de etiquetas personalizadas JSP que cooperan con el controlador para su uso en la parte
de la vista de MVC
Distintas opciones para la validación de entrada de usuario en formularios HTML:
ActionForm
Validator Framework
Mecanismos para el tratamiento de errores
Soporte para la internacíonalización (i18n) a través de ficheros de recursos y Java Locales
Soporte para fuentes de datos

@javioliful


l  Además el grupo Struts siempre da la bienvenida a nuevos participantes.
Para convertirse en colaborador, se recomienda formar parte primero de la
lista de distribución de Struts. Si te gusta lo que allí aparece puedes echar
un vistazo a la lista de Struts Developers. La página principal del proyecto
está ubicada en http://jakarta.apache.org/struts.


@javioliful

Página del proyecto Apache.

Alternativas a Struts
l  Otros marcos de trabajo comparables a Struts pueden ser elegidos como
alternativas a éste. A continuación se citan algunos de los proyectos más
interesantes que han venido desarrollándose en los últimos tiempos:
l  Barracuda MVC
¡  El entorno de trabajo es un tipo de de arquitectura similar al Modelo 2 de Struts,
pero va más allá, proporcionando mecanismos de notificación basada en
eventos
al modelo. Además, proporciona vistas generadas en base a un motor de
plantilla,
y cuya formación se hace a través de XML (XMLC) y no exclusivamente JSP.
Podemos encontrar más documentación en
http://www.barracudamvc.org/Barracuda/docs/index.html.

l  Cocoon
¡  Stefano Mazzocchi fundó este proyecto en enero de 1999 como un proyecto de
código abierto bajo la ASF. El objetivo era separar el estilo de contenido , la
lógica y las funciones de gestión para los sitios Web basados en XML. Influye
por lo tanto en XML (XSLT,SAX) para ayudar a crear, desarrollar y mantener
aplicaciones de servidor XML. Más información podemos encontrarla en
http://cocoon.apache.org

@javioliful


Alternativas a Struts (II)
l  Expreso
¡  Expresso, de Jcorporate, es un marco de desarrollo de aplicación que proporciona un marco
de trabajo basado en componentes. Proporciona una serie de componentes principales
compatibles tanto con aflicciones EJB como no EJB. Aunque completamente independiente
de Struts y otros marcos, los componentes Expresso también se pueden integrar con Struts
con el fin de añadir posibilidades de segundad, mapeado de objeto-a-relacional, gestión de
trabajo en segundo plano, etc. Más información en http://www.jcorporate.com.

l  Freemarker, Velocity y Web Macro
¡  Estos tres productos se agrupan por que representan tipos similares de motores
de plantilla. Freemaker genera HTML dinámicamente utilizando datos
proporcionados por servlets y mediante su propio lenguaje de plantilla. Velocity es
otro proyecto Jakarta como Struts, pero va más allá de la generación de HTML ya
que puede generar SQL, PostScritp y XML desde plantillas. Velocity utiliza un
lenguaje de script ligero que separa la lógica de las páginas del aspecto. Más
información sobre estos marcos se puede encontrar en
http://freemaker.sourceforqe.net,
http://jakarta.apache.org/velocity y
http://www.webmacro.org.

l  Maverick
¡  Ofrece la posibilidad de mostrar vistas utilizando JSP, el lenguage de script de Velocity o
XSLT. Maverick es una arquitectura de tipo MVC paro proporciona un mecanismo de
plantilla de vistas. Para más información se puede consultar http://mav.sourceforqe.net.


@javioliful


Alternativas a Struts (III)
l  Spring
¡  Es un marco para aplicaciones J2EE relativamente nuevo desarrollado por Rod
Jonson. No solamente es un marco Web, sino que permite la posibilidad de estar
integrado con otros componentes de naturaleza dispar. Consultar
http://www.springframework.org.

l  Java Server Faces
¡  Proporciona un conjunto estándar de etiquetas JSP, controladores, gestión de
eventos, etc. Que no solamente permiten el desarrollo web, sino el de
aplicaciones de naturaleza Java tales como Java Swing. Incluido en los
estándares J2EE de Sun y cuya documentación podemos encontrarla en
http://java.sun.com/javaee/javaserverfaces.

l  Esta lista puede ser completada con SiteMesh, Jakarta Turbina,
WebWork, además de marcos desarrollados por otras tecnologías tales
como UIP (User Interface Process) de Microsoft cuyos objetivos son
compartidos por Struts aunque desarrollados para su utilización en modelo
de programación .NET.


@javioliful


Instalando Struts
l  Una aplicación de struts es una aplicación web, por lo que vamos a
necesitar un servidor web y un contenedor de componentes web para su
despliegue y ejecución.
l  Necesitamos instalar la cualquiera de las versiones de Apache Struts, lo
podemos hacer de la siguiente dirección:
l  http://struts.apache.org/download.cgi o http://archive.apache.org/dist/struts
l  En nuestro caso, descargaremos el fichero struts-1.2.7.zip.
l  En el directorio webapps de la distribución de Struts se pueden encontrar
varios ficheros .war muy útiles.
¡ 
¡ 
¡ 
¡ 


struts-blank.war: Es la base para cualquier aplicación.
struts-documentation.war: Documentación del framework.
struts-examples.war: Aplicaciones de ejemplo.
Etc.

@javioliful


Tema 2: Primera aplicación
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 

Introducción
Control de flujo en Struts
Diagrama de clases
Primer programa
Petición http y Action
La clase Action
Las vistas
El uso de Forward
El archivo de configuración struts-config.xml
El descriptor de despliegue de la aplicación (web.xml)
La estructura de la aplicación
Despliegue y ejecución
Atención de la petición


@javioliful


Introducción
l  En este capítulo vamos a desarrollar la típica aplicación de ejemplo al más
puro estilo "HelloWorld". Para ello hemos de disponer de las herramientas,
librerías ya comentadas en el capítulo anterior.


@javioliful


Control de flujo en Struts
l  Cuando programamos con servlet y JSP directamente, somos
responsables del flujo de navegación.
l  Para ello usamos RequestDispatcher u otros mecanismos que nos
reencaminen hacia los componentes que determinemos en base a la
información que el cliente nos proporciona en su petición http.
l  No obstante, si usamos un framework como Struts El desarrollador será
responsable de la lógica de negocio, de la vistas, etc.. pero no del control
del flujo ni otros aspectos que se suponen comunes para este tipo de
aplicaciones; validación, intemacionalización, etc.
l  Este control se definirá de forma declarativa usando archivos xml. De
esta forma damos flexibilidad a nuestras aplicaciones, pudiendo reutilizar el
sistema de control de flujo en cada uno de los sistemas que estemos
construyendo.


@javioliful


Control de flujo en Struts (II)
l  A continuación se citan los componentes que están implicados en una
aplicación web en lo que al control de flujo y tratamiento de las peticiones
se refiere:
¡  La clase org.apache.struts.action.ActionServIet es el eje de Struts. Dada una
petición de entrada HTTP:
1.  Crea un objeto ActionForm donde guarda y valida los parámetros de entrada
2.  Decide qué objeto Action se debe invocar y le pasa el objeto ActionForm creado
3.  Transfiere el control a la siguiente etapa de procesamiento de la petición (típicamente
un JSP).

l  El fichero de configuración web.xml contiene los url mappings para enviar las
peticiones de llegada al ActionServIet, mientras que el fichero de configuración
de Struts struts-config.xml contiene los mappings a acciones


@javioliful


Control de flujo en Struts (III)
l  Los formbeans creados por ActionServIet deben ser implementados por el
programador, extendiendo org.apache.struts.action.ActionForm.
¡  El programador deberá definir un conjunto de getters y setter y sobreescribir
los métodos validate() y reset()

l  Los objetos Action invocados deben ser desarrollados por el programador
y extienden org.apache.struts.action.Action. Tienen un método execute()
que ejecuta la lógica de negocio.
l  La acción devuelve un objeto ActionForward al servlet que especifica el
siguiente paso a ejecutar, normalmente se transfiere el control a un JSP
para que visualice los resultados.


@javioliful


Diagrama de clases
l  Diagrama:


@javioliful


Primer programa
l  Vamos a crear el primer ejemplo con struts. Esta aplicación no tiene
entrada, y el resultado de salida es el típico "Hola Mundo" de todos los
lenguajes de programación.
l  Copiar las siguientes librerías en la carpeta lib de WEB-INF:
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 

antlr.jar
commons-beanutils.jar
commons-digester.jar
commons-fileupload.jar
commons-logging.jar
commons-validator.jar
jakarta-oro.jar
struts.jar

l  Estas librerías se encuentran en la carpeta lib del directorio de instalación
de struts.


@javioliful


Petición http y Action
l  Las acciones responden a peticiones http (request). Cuando escribimos un
Action hemos de extender de la clase org.apache.struts.action.Action y
sobreescribir su método execute. Este método servirá para el tratamiento
de la petición.
l  El método execute devuelve un ActionForward. Podemos pensar en un
ActionForward como en una vista de salida, o lo que es lo mismo,
dependiendo el ActionForward que hayamos obtenido, se reencaminará el
flujo hacia una vista u otra.
l  El método execute recibe cuatro argumentos:
¡ 
¡ 
¡ 
¡ 

un ActionMapping
un ActionForm
un HttpServIetRequest
un HttpServIetResponse

l  El ActionMapping es el objeto en el que se manifiesta el elemento XML
usado para configurar el Action en el fichero de configuración de struts. El
ActionMapping contiene un grupo de ActionsForwards asociados con la
acción actual.


@javioliful


La clase Action
l  Siguiendo lo expuesto con anterioridad.La clase Action será la que se corresponda
con el caso de uso que se está desarrollando.

Esta clase Action nos lleva hacia una vista de salida llamada bien, o hacia una vista de salida
llamada error, dependiendo del valor de un parámetro de la petición. Estas vistas de salida,
ActionForward, serán páginas JSP (hola.jsp y error.jsp)

@javioliful


Las vistas
l  La página de error y la de bienvenida, son similares. Utilizarán de forma
muy básica los recursos que la tecnología JSP nos proporciona. Sin entrar
en detalles que más adelante comentaremos, tales como desacoplamiento
de mensajes, internacionalización, validación, etc.
error.jsp


@javioliful


Las vistas (II)
hola.jsp


@javioliful


El uso de Forward
l  Un forward es una vista de salida, como hemos dicho.
l  Pero lo único que hemos puesto como argumento en el método
findForward de la clase ActionForward, ha sido un nombre lógico, no una
dirección, esto nos permitirá mayor desacoplamiento entre las distintas
partes de la arquitectura, pero debemos proporcionar una forma de
relacionar este nombre lógico con una URL que nos dirija hacia el forward
de salida.


@javioliful


El archivo de configuración strutsconfíg.xml
l  Para ligar los nombres lógicos de la redirección anteriormente establecida y
las vistas asociadas a los mismos debemos actuar en el archivo de
configuración de struts.
l  El fichero de configuración de struts se llama struts-confíg.xml.
l  Esta correspondencia entre el nombre lógico del forward, y la url de la
página jsp de salida, se establece en el elemento action-mappings. Este
elemento contiene los elementos action.


@javioliful


El archivo de configuración strutsconfíg.xml (II)
l  En el caso del ejemplo, este fichero de configuración es como se muestra a
continuación:
l  struts-confíg.xml


@javioliful


El archivo de configuración strutsconfíg.xml (III)
l  El elemento action tiene dos atributos:
¡  path
¡  type

url lógica que representa a la acción
nombre totalmente cualificado de la clase Action

l  El elemento action contiene los elementos forward. Mediante los atributos
name y path de este elemento, se asocia el nombre lógico del forward con
la url de la página jsp.
l  La ubicación de este fichero de configuración de struts, struts-config.xml,
se especifica como parámetro de incicialización del ActionServIet de struts,
dentro del archivo web.xml de la aplicación web.


@javioliful


El descriptor de despliegue de la
aplicación (web.xml)
l  En el caso del ejemplo, el archivo web.xml es como se muestra a
continuación:


@javioliful


El descriptor de despliegue de la
aplicación (web.xml) (II)

l  En este archivo de configuración web.xml se indica que todas las url de
extensión .do sean procesadas por el ActionServIet de struts. Este
ActionServIet lee el fichero de configuración struts-config.xml donde se han
asociado previamente los nombres lógicos de los forward con las url de las
páginas jsp de salida.


@javioliful


La estructura de la aplicación
l  La estructura de nuestra primera aplicación web deberá corresponder a la
estructura que J2EE especifica para los módulos web. En nuestro caso
será la siguiente:


@javioliful


Despliegue y ejecución
l  Para ejecutar la aplicación, debemos asegurarnos de tener arrancado el
servidor y usando un navegador web, realizar la petición sin olvidar el
sufijo .do y acorde a como la hayamos definido en el struts-config.xml.
Además, pasaremos el parámetro de la petición en la misma barra de
direcciones.
l  El resultado en ejecución se muestra a continuación:


@javioliful


Despliegue y ejecución (II)
l  Si omitimos el argumento, el resultado cambia:

Dependiendo del valor del parámetro se muestra una vista u otra.


@javioliful


Atención de la petición
l  El siguiente diagrama no da perfecta idea del comportamiento que tiene una
aplicación struts cuando atiende una perición http de forma genérica.


@javioliful


Tema 3: Integración con la capa de datos
¡ 
¡ 
¡ 
¡ 

Usando JDBC con Struts DataSources
Configuración del DataSource
Implementación del nuevo caso de Uso
El objeto de negocio y el DAO


@javioliful


Usando JDBC con Struts DataSources
l  El uso de Struts DataSources, fuentes de datos de struts, nos permite
obtener los beneficios de los datasources sin depender de ninguna
implementación propietaria. Por una parte, esto hace que nuestra
aplicación sea más portable y por otro, no estamos obligados a usar alguna
de las características más avanzadas de la implementación particular, si es
que no fuera necesario.
l  Para trabajar con struts datasources vamos a necesitar dos nuevas
librerías .jar:
¡  commons-pooling.jar
¡  commons-dbcp.jar

l  Estas librerías no vienen con la instalación de struts, así que tenemos que
descargarlas de la siguiente dirección de internet:
l  http://jakarta.apache.org/site/downloads/downloads commons-pool.cgi
l  http://jakarta.apache.org/site/downloads/downloads commons-dbcp.cgi


@javioliful


Configuración del DataSource
l  Lo primero que tenemos que hacer es configurar el datasource dentro del
archivo de configuración de struts (struts-config.xml). Para ello existe el
elemento data-sources, que contiene tantos data-source como fueran
necesarios en nuestra aplicación. En el caso de nuestro ejemplo, la
configuración del datasource queda como se muestra a continuación:
l 

Fragmento struts-config.xml


@javioliful


Configuración del DataSource (II)
l  El datasource se marca con una clave, que es el atributo key, que servirá,
dentro de la clase Action que lo maneje, para obtener el objeto en caso de
que haya más de un DataSource declarado. Mediante el uso de las
distintas propiedades se establece nombre de la clase del driver, la URL de
conexión, las características del pool de conexiones que maneja el
contenedor, etc..


@javioliful

Configuración del DataSource (III)
l  El código de la clase Action que maneja el DataSource es el que se
muestra a continuación: consultarTodos.java
l 


@javioliful

l  Para poder dotar a nuestra aplicación del nuevo caso de uso (el catálogo
de artículos) debemos hacer las siguientes modificaciones en nuestra
aplicación:
1.  Añadir la declaración del DataSource en struts-config.xml. Este paso ya ha
sido expuesto anteriormente
2.  Añadir la nueva acción "verArticulos", junto a la clase Action que
lo implementa así como su vista asociada "verTodos.jsp".

3.  Recorrer en la vista la colección de Artículos. La página verTodos.jsp, es parte
de la vista, no es motivo de estudio en este ejemplo. No obstante adelantamos
que el cometido de la misma es recuperar de la petición (request) una colección
de "Transfer Objects" y llevar a cabo su recorrido para mostrarla de forma
atractiva al usuario.


@javioliful


l  verTodos.jsp


@javioliful


l  Articulo.java


@javioliful

El objeto de negocio y el DAO (II)
l  ArticuloDAO.java


@javioliful

Obtener la conexión del Contexto
l  Si queremos conseguir el origen
de datos del contexto de la aplicación
deberemos registrarlo en el archivo
del Tomcat: conf/Context.xml

l  Y posteriormente obtenerlo
por JNDI en el ADO
o donde queramos)


@javioliful


Tema 4: Manejo de formularios
¡  Introducción
l 
l 
l 
l 
l 
l 
l 

Form Beans
Definición de un Form Bean
Ejemplo de un Form Bean
Configuración del Form Bean
Lógica de negocio (Action)
Mostrando la información obtenida
Ejecución de la aplicación

¡  Validación de formularios


@javioliful


Introducción
l  En este capítulo mostraremos la forma de interactuar por parte de los
usuarios con nuestra aplicación struts mediante el uso de formularios y de
los distintos tipos de componentes ActionForm que se generan en cada
llamada.


@javioliful


Form Beans


@javioliful


Form Beans
l  Un ActionForm es un JavaBean con propiedades que corresponden a los
controles de un formulario HTML.
l  Los parámetros son mapeados a propiedades del bean.
l  Estos componentes proveen un mecanismo de validación que es necesario
para asegurarnos que el usuario introduce los datos esperados. En
definitiva, actúan como puente entre el navegador y lo objetos de negocio.


@javioliful


Definición de un Form Bean
l  El programador define un form bean extendiendo la clase
org.apache.struts.action.ActionForm. También puede definirse de forma
declarativa usando usando org.apache.struts.action.DynaActionForm.
Además, deben tener las siguientes características:
¡  Hay que definir cada una de las propiedades en la clase y escribir los getters/
setters correspondientes, siguiendo las reglas de la convención de nombres de
los JavaBeans
¡  Después de escribir el código del form bean, es necesario asociarlo con una o
más acciones a través del fichero de configuración de Struts struts-config.xml

l  Cada vez que se llama a la acción , el ActionServIet rellenará las
propiedades con los valores de los parámetros recibidos en el formulario
HTML que deberá ser definido usando etiquetas de la librería de Struts.
l  Nota: Las propiedades no sólo pueden ser escalares sino que también
pueden ser colecciones de valores.


@javioliful


Ejemplo de un Form Bean
l  Supongamos que deseamos consultar un artículo de nuestro catálogo.
Para ello proporcionaremos un formulario en nuestra página de entrada de
datos que llamaremos verUnoInput.jsp, y cuyo fragmento de código se
muestra a continuación en lo que al formulario se refiere.
l  verUnoInput.jsp (código)

l  verUnoInput.jsp (en navegador)


@javioliful


Ejemplo de un Form Bean (II)
l  Necesitaremos un Form Bean que ecapsule la información de la cajita de
texto ("id") que usuario rellenará con el valor de la clave primaria del
articulo que se está buscando, esta propiedad deberá hacerse
corresponder con la propiedad "id" el Form Bean (Action Form).
l  Veamos el código de VerUnoForm.java.


@javioliful


Ejemplo de un Form Bean (III)


@javioliful


Configuración del Form Bean
l  Al igual que el resto de componentes, hemos de dar de alta en el fichero de
configuración de struts el componente, dándole un nombre para poder
asociarlo con una acción.
l  En fichero hemos de indicar además la clase que implementa el form. En
nuestro ejemplo, la clase es app.view.VerUnoForm y le hemos dado el
nombre verUnoForm.


@javioliful


Fragmento de struts-config.xml


@javioliful


Lógica de negocio (Action)
l  Por supuesto todo esto no vale para nada si detrás no hay el
correspondiente Action que obtiene la información del bean e invoca a la
lógica de negocio.
l  Es importante observar el modo de hacer el casting hacia el tipo de Form
Bean adecuado y que previamente hemos definido unas líneas más arriba.


@javioliful


Lógica de negocio (Action) (II)


@javioliful


Mostrando la información obtenida
l  Tal y como expusimos en el capítulo anterior durante el desarrollo del caso
de uso verTodos, mostramos a continuación el fragmento de código que
permitirá recuperar del request un objeto y acceder a sus propiedades.
Para ello utilizaremos etiquetas personalizadas logic
l  verUno.jsp


@javioliful


l  Si introducimos un indentificador acorde a la validación que hemos hecho
en el Action Form obtendremos el resultado esperado.


@javioliful


Ejecución de la aplicación (II)

! Si por el contrario dejamos el campo de texto en blanco,
volveremos a la pagina verUnoInput.jsp


@javioliful


Tema 5: Validación de formularios
¡  Validación de formularios
l  Framework Validator

¡  Introducción
l  Uso del Framework Validator
l  Respecto al Action

¡ 
¡ 
¡ 
¡ 

Reglas de validación comunes
Validación en el lado del cliente con JavaScript
Uso y Validación de DynaActionForms
l  Validación de un DynaActionForm
l  Lectura de propiedades de un DynaActionForm

¡  Validación del lado del cliente


@javioliful


Validación de formularios
l  Como hemos visto, es de vital importancia por muchos motivos la correcta
introducción de los datos por parte del usuario. Aquellos datos que el
cliente no introduzca correctamente, formato, longitud, etc.. no deberían
viajar al servidor por lo que una capa de verificación (validación de datos)
por JavaScript del lado el cliente puede ser interesante. Proponemos una
solución para realizar una validación básica que permita obtener con el
mínimo esfuerzo esta capa software. Se trata del Framework Validator


@javioliful


Framework Validator
l  Introducción
l  El Framework Validator se utiliza para validar campos. La validación de
un campo determinado se puede realizar en múltiples formularios. Por
ejemplo, el código postal de un usuario se debe validar en el formulario de
registro y también en un formulario de pedido. Podemos escribir dicha
validación en el método valídate de cada uno de los ActionForm,
duplicando el código, o podemos crear un mecanismo general de validación
para todos los códigos postales que manejemos en nuestra aplicación.
l  Existen muchas reglas de validación que podemos usar y además,
tenemos la posibilidad de crear nuestras propias reglas en caso de que
fuera necesario.


@javioliful


Uso del Framework Validator
l  Para introducirnos en la utilización de este framework, vamos a seguir de
nuevo, paso a paso el ejemplo que estamos desarrollando a lo largo del
manual. Vamos a validar el nombre de usuario del formulario de registro.
Las reglas que establecemos para darlo por válido son:
¡  Que tenga un mínimo de 3 caracteres
¡  Que tenga un máximo de 8 caracteres


@javioliful


l  Hemos de seguir los siguientes pasos:
l  1. Lo primero que tenemos que hacer es añadir el plug-in Validator en el
fichero de configuración de struts. El framework Validator se integra con
struts a través de este plug-in, el cual es responsable de leer los ficheros de
configuración para las reglas de validación. El elemento plug-in debe
incorporarse al fichero de configuración de struts después de cualquier
elemento message-resources. En el caso de nuestro ejemplo, el fichero de
configuración struts-config.xml se completa como se muestra a
continuación:
l  Struts-config.xml


@javioliful


l  2. Hemos de copiar los archivos validator-rules.xml y validation.xml
dentro de la carpeta WEB-INF de nuestra aplicación. Estos archivos se
encuentran en la aplicación de ejemplo que viene con la instalación de
struts (struts-blank.war).
l  Por el momento no vamos a modificar el archivo validator-rules.xml, ya
que vamos a utilizar las reglas de validación que nos proporciona struts.
l  El archivo validation.xml nos proporciona el mapeo entre la propiedad del
ActionForm, las reglas de validación que se le aplican y el mensaje de error
correspondiente.


@javioliful


l  3. Hemos de cambiar la clase ActionForm con la que trabajamos
(RegistrarUsuarioForm.java) para que extienda de
org.apache.struts.validator.ValidatorForm. Esta clase es el nexo de
unión entre Struts y el framework Validator.
l  La clase ValidatorForm sobrescribe el método validate() y le comunica al
framework Validator que aplique las reglas de validación a los campos de
este formulario.
l  Así que modificamos el código del formulario para que quede de la
siguiente manera:


@javioliful


l  VerUnoValidatorForm.java


@javioliful


l  Añadimos el formulario dentro del archivo validation.xml, del siguiente modo:
l  Validation.xml

l  Un detalle importante. Como valor del atributo name para el form, se ha puesto
el mismo nombre que lo asociaba a su action en el archivo struts-config.xml
l  struts-config.xml


@javioliful


l  4. Añadimos un elemento field a la declaración del formulario en el archivo
validation.xml correspondiente al campo usuario. Después le asociamos las
distintas reglas de validación que le queremos aplicar:

l  El atributo depends toma como valor la lista de reglas aplicables al campo,
separadas por comas. En este caso se asocian las reglas required, minlength y
maxlength. Estas reglas se encuentran definidas dentro del archivo validatorrules.xml y forman parte del framework Validator. Por ejemplo, si miramos la regla
para minlength en el archivo validator-rules.xml, vemos lo siguiente:

@javioliful


l  validator-rules.xml

l  En esta definición se asocia el nombre de la regla con la clase utilizada para la
validación y que implementa la regla, y la clave para el mensaje que el framework
debe mostrar en caso que se produzca un error en la validación. Esta clave debe
asociarse al mensaje dentro del archivo de recursos de la aplicación.


@javioliful


l  5. Añadimos los mensajes de error con sus claves dentro del archivo de
recursos de la aplicación. Podemos tomar como ejemplo los
proporcionados por el archivo validator-rules.xml de la aplicación de
ejemplo de struts:
l  MessageResources.properties


@javioliful

l  Este fichero debe ser alojado en la aplicación y declarado en strutsconfig.xml. Contendrá a modo de pares clave, valor los mensajes que se
deberán ir mostrando en cualquiera de los aspectos de la aplicación;
errores, mensajes de advertencia, títulos, etc.
l  La declaración en el struts-config.xml se hará de la siguiente forma.

l  La ubicación y su localización tendrá la misma forma que las clases
Java, por lo que en el caso de nuestro ejemplo,
"app.view.ApplicationResources" nos indicará que el fichero está en el
directorio
.../WEB-INF/classes/app/view.


@javioliful


l  Podemos adaptar nuestro archivo de recursos y adaptarlos a nuestras
necesidades, incluyendo literales, variables etc.
l  Fragmento de nuestro ApplicationResources.properties

l  Observa que los mensajes de error toman un argumento en el caso de la
regla required y dos en las otras dos reglas. Hemos de configurar estos
argumentos.


@javioliful


l  6. El primer argumento del que se habla en el punto anterior, va a indicar
la etiqueta del campo validado, y el segundo el número de caracteres que
se permiten como máximo y mínimo respectivamente. Esto se ha de
configurar en el archivo validation.xml:

l  Se incluye un elemento <var> por cada parámetro que se evalúa

@javioliful


l  Observamos de nuevo el mensaje error asociado a la clave de longitud
mínima:

l  El argumento {0} lo leemos del archivo de recursos de nuestra aplicación.
Es decir, en <arg0 key="verUno.id"/> observamos la clave "verUno.id", así
{0} será el literal asociado a dicha clave en
ApplicationResources.properties, pero el segundo corresponde al valor que
hemos asociado a la variable minlength. Es decir, este dato no lo
obtenemos del archivo de recursos, sino de la propia variable definida en el
archivo validation.xml mediante el par de entradas <var-name>/<var-value>
y asociada al argumento <arg1>. En definitiva, y resumiendo: {0}, {1}, {2} se
sustituirá por <arg0>, <arg1> y <arg2>.


@javioliful


Respecto al Action
l  Recordemos que el Action (verUnoAction), es decir, el objeto que ecapsula
las llamadas a la lógica de negocio, usaba la clase verUnoForm para
obtener la información del exterior ("id"). Ahora hemos alterado esta
situación, ya que usamos verUnoValidatorForm y por tanto habrá que
hacer modificaciones en la clase, ya que el casting debe ir hacia esta clase
y no la anterior. Es muy común, por otra parte, olvidar este pequeño detalle,
dando lugar a errores de incómoda búsqueda.
l  En este ejemplo nos crearemos un Actión nuevo para hacer la prueba.
l  Fragmento de VerUnoActionValidator.java


@javioliful


Respecto al Action
l  Tambíen nos crearemos un jsp nuevo para la prueba, pues tendrá que
llamar nuevo Action.
l  Fragmento de verUnoInputValidator.jsp

l  Configuración definitiva en del action en el struts-config.xml


@javioliful


l  Si ejecutamos la aplicación ahora, y no cumplimos con los requisitos del
campo, struts nos redireccionará el flujo de la aplicación de nuevo al input,
en nuestro caso verUnoInputValidator.jsp.


@javioliful


Reglas de validación comunes
l  En la siguiente tabla se recogen las reglas de validación que incluye el
framework Validator


@javioliful


Validación en el lado del cliente con
JavaScript
l  Es bastante común realizar una validación en el lado del cliente con
javascript. Esto evita que los datos viajen al servidor mientras no cumplan
las condiciones de validación. El framework Validator tiene un mecanismo
para generar código JavaScript. Para utilizar javascript tenemos que hacer
lo siguiente:
l  1. Añadimos una etiqueta html:javascript a la página jsp, del siguiente
modo:


@javioliful


JavaScript
l  2. Para validar el formulario en el lado del cliente tenemos que añadir a la
etiqueta html:form el atributo onsubmit, del siguiente modo:

l  Importante: El nombre del método valídate, se forma acompañando al
valor del atributo formName anterior, empezando con mayúscula.
l  Si el valor de retorno es false, los datos no se envían al servidor.


@javioliful


JavaScript
l  Si hacemos los cambios mencionados, y accedemos a la página jsp de alta
de usuario, podemos ver el código javascript generado:


@javioliful


l  Una de las primeras críticas que recibieron las primeras versiones de
Struts, fue que se consideraba que era tedioso tener que crear una clase
ActionForm por cada formulario (clase sencilla pero que suponía tener
los correspondientes get() y set() de cada dato).
l  Esto además suscita un problema en la teórica separación de roles, ya
que tanto los diseñadores de JSP como los programadores de los Actions,
debían ponerse de acuerdo en los campos de los formularios, pues si no se
producirán.
l  Los desarrolladores demandaron alguna forma más ágil y dinámica de
declarar estos componentes por lo que desde la versión 1.1 de Struts se
cuenta con los DynaActionsForms.


@javioliful


l  Estos ActionForms deberán ser declarados en el fichero strutsconfig.xml, de manera que quedarán a modo de entradas xml la
definición de los campos y los tipos de datos de cada ActionForm.
l  La diferencia con los ActionForms tradicional reside en que se añaden las
etiquetas "<form-property>" para definir cada uno de los campos. Para
cada campo hay que declarar su nombre ("name"), el tipo de dato ("type")
y, opcionalmente, un valor inicial ("inicial").


@javioliful


l  Los tipos de datos aceptados por los ActionForm de tipo DynaActionForm
son:
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 

BigDecimal
Biglnteger
Boolean
Byte
Character
Double
Float
Integer
Short
Long
String
Date
Time
Timestamp
Tipo primitivos (int, char, long....)


@javioliful


l  Configuración de DynaActionForm en el Struts-config.xml
l  Definición del form-bean:
Podemos observar en la propiedad id
declarada en la etiqueta <form-property
name="id“ type="java.lang.string"/>, que
recordemos que es la usada para
obtener los Articulo en cuestión.

l  Definición del Action:

Los únicos cambios que se dan en el struts-config.xml. El caso de uso relacionado con la
acción verUno se verá afectado ya que usaremos ahora verUnoDynaActionForm,
declarado en la etiqueta <action path="/verUno"
input="/verUnoInput.jsp" name="verUnoDynaActionForm">.

@javioliful


Validación de un DynaActionForm
l  La validación en un DynaActionForm no requiere grandes cambios, tan solo
modificaciones en el archivo validation.xml. Las reglas de validación,
seguirán siendo las mismas y por lo tanto el framework validator sequirá
actuando de la misma forma:
l  Fragmento afectado del validation.xml:


@javioliful


Lectura de propiedades de un
DynaActionForm
l  Como hemos visto en el tratamiento de las peticiones, es la case Action la
encargada de tratar la peticiones y, por lo tanto, de extraer los parámetros
del Java Bean (ActionForm) correspondiente. La extracción de las
propiedades del un ActionForm tradicional (con o sin validación) se basaba
en la llamada al método getXyz(), siendo Xyz la propiedad en cuestión.
l  Usando DynaActionForms, no hay tales métodos getXyz() ni set Xyz(), ya
que las propiedades se generarán de forma dinámica y no hay una clase de
respaldo que modele las mismas. La forma de extraer la información será a
partir del método get("xyz") disponible en la clase
org.apache.struts.action.DynaActionForm. Veamos la porción de código
afectada.


@javioliful


Lectura de propiedades de un
DynaActionForm
l  Fragmento de Action afectado:


@javioliful


Validación del lado del cliente.
l  Ya hemos justificado la necesidad de validar los datos de entrada en el lado
del cliente usando rutinas JavaScript. Es evidente que el uso de
DynaActionForm no condiciona el mecanismo general de validación, no
obstante hay que tener en cuenta los cambios a realizar en las páginas JSP
para evitar sorpresas en tiempo de ejecución. Vemos a continuación el
código de verUnoInput.jsp.


@javioliful


Validación del lado del cliente.
l  verUnoInput.jsp (modificaciones)


@javioliful


Tema 6: Tratamiento de excepciones
¡  Excepciones con struts
¡  Tratando excepciones globales


@javioliful


Excepciones con struts
l  En todos los programas se producen errores. Nuestro trabajo como
programadores es evitar que el usuario final se encuentre con un
resultado desagradable si esto sucede. Lo más probable es que no
queramos que el usuario de nuestro sitio web vea un stack trace de error
que posiblemente no entienda.
l  En el caso del ejemplo que nos ocupa, si tratamos de consultar un Articulo
que no existe en nuestro catálogo, la aplicación retornará una
DAOException, provocada por ArticuloDAO. En definitiva una excepción de
Usuario. Trabajando con struts podemos definir un manipulador de
excepciones (exception handler) para manejar la excepción. Un
exception handler nos permite manipular una excepción de manera
declarativa en el archivo de configuración struts-config.xml asociando una
excepción a un mensaje comprensible por el usuario dentro de una página
jsp que será mostrada al usuario si la excepción ocurre.
l  Vamos a seguir los siguientes pasos:


@javioliful


l  1. Creamos una página jsp llamada registroException.jsp en la raíz de
nuestra aplicación. En ella incorporamos la etiqueta html:errors para
mostrar el mensaje asociado con la excepción:
l  registroException.jsp


@javioliful


l  2. Añadimos una entrada en el archivo de recursos de la aplicación,
ApplicationResources.properties bajo la clave errors.verUno.exception,
que explique la naturaleza del problema en términos que el usuario
final pueda entender fácilmente. Por ejemplo:
l  ApplicationResources.properties


@javioliful


l  3. Añadimos un exception handler en el action mapping para /verUno
que maneje la excepción app.modelo.DAOException del siguiente modo:
l  Struts-config.xml

l  Observa que el elemento exception tiene tres atributos:
¡  key.- asocia el exception handler con una entrada del archivo de recursos.
¡  type.- Asocia el exception handler con el tipo de la excepción a tratar.
¡  path.- asocia el exception handler con la página jsp que se muestra si la
excepción ocurre.

@javioliful


l  El resultado en ejecución:


@javioliful


Tratando excepciones globales
l  Al igual que se pueden tener forwards globales, independientes de
cualquier acción, también podemos definir un tratamiento global a las
excepciones, es decir, independientemente de la acción que las provoque.

l  Una acción particular puede establecer el tratamiento de una excepción
que haya sido definida como global exception. El caso particular predomina
sobre el general.


@javioliful


l  Para definir un tratamiento global de las excepciones, seguimos los
siguientes pasos:
l  1. Definimos una entrada para la excepción en el archivo de
recursos de la aplicación:


@javioliful


l  2. Dentro del archivo de despliegue de la aplicación, struts-config.xml,
definimos un elemento gobal-exceptions, que contiene tantos elementos
exception como excepciones queramos tratar.

l  El elemento exception tiene tres atributos:
¡  key.- Corresponde a la entrada dentro del archivo de recursos de
la aplicación.
¡  type.- Tipo de excepción tratada.
¡  handler.- Nombre totalmente cualificado de la clase que trata el evento. Esta
clase debe extender de org.apache.struts.action.ExceptionHandler.

@javioliful


l  Escribimos la clase que extiende de ExceptionHandler. En el caso del
ejemplo, el código es el que se muestra a continuación:
l  GestorProblema.java


@javioliful


l  Esta clase tiene un método execute que, entre otros, recibe como
argumento un objeto de la clase Exception. Dentro del método execute se
codifica la respuesta a la excepción. En este caso se imprime la traza
de la excepción en la salida estándar del servidor de aplicaciones, y se
dirige al usuario hacia la vista de salida marcada con el nombre
problemaGenerico.
l  Este forward se incluye en el archivo descriptor de despligue strutconfig.xml dentro del elemento global-forwards


@javioliful


l  Si se produce el error, se muestra al usuario la página html de error. En
el caso de nuestro ejemplo, si se produce un error inesperado se muestra
al usuario la siguiente vista de salida:


@javioliful


Tema 7: Internacionalización
¡ 
¡ 
¡ 
¡ 

Internacionalización (I18N)
Configuración de nuestro navegador
Mostrando mensajes variables
La etiqueta <bean:message>


@javioliful


Internacionalización (I18N)
l  Trabajando con struts podemos hacer, de forma sencilla, que nuestra
aplicación se presente ante el usuario en el idioma que tenga configurado
como preferido en su navegador. O bien mostrarla en el que el usuario elija
de los distintos propuestos en una página de inicio.


@javioliful


Configuración de nuestro navegador
l  Cada región (geográfica, política o social) se identifica mediante un estándar
formado por dos letras minúsculas. Podemos ver las distintas combinaciones en
el cuadro de configuración del idioma de nuestro navegador:

Para el idioma inglés, por
ejemplo, existen distintas
combinaciones de letras,
según la región, así como
para otros idiomas como el
español o el francés.


@javioliful

Elegir el idioma
l  Vamos a hacer que nuestra aplicación se muestre en inglés o en español,
según el idioma preferido del usuario. Pero también podemos inventarnos
nuevos idiomas usando sufijos a nuestra conveniencia. Seguimos los
siguientes pasos:
l  1. Dentro del archivo struts-config.xml, añadimos la siguiente acción:

l  En el action podremos modificar de forma programática el idioma y no sólo
para idiomas predefinidos sino que podremos mostrar nuestros propios
dialectos. En nuestro caso pasaremos la cadena del dialecto escogido
usando parámetros de un formulario o directamente en la url. .../
cambiarIdioma?lenguaje=xx, donde xx puede ser un idioma inventado o
bien cualquiera que los estándares definen.


@javioliful


Elegir el idioma
l  CambiarldiomaAction. java


@javioliful


Elegir el idioma
l  2. Para que las etiquetas del formulario se muestren en un idioma
determinado, hemos de incorporar tantos archivos de recursos como
idiomas se contemplen. Estos archivos deben contener en su nombre la
representación estándar del idioma. En nuestro caso teníamos el archivo
de recursos ApplicationResources.properties y ahora hemos de
incorporan uno nuevo, ApplicationResources_xx.properties. Dentro de
este archivo, y asociados a las mismas claves que el primero, se
encuentran los mensajes en el idioma xx:
l  Fragmento de ApplicationResources_en.properties


@javioliful


Elegir el idioma
l  Podemos crear cuantos archivos paralelos deseemos, cuyos sufijos
nos indicarán el idioma en que queremos trabajar.
¡ 
¡ 
¡ 
¡ 

ApplicationResources_en.properties
ApplicationResources_en_GB.properties
ApplicationResources_es.properties
ApplicationResources_xx.properties

l  Si disponemos de estos archivos en nuestra aplicación, no será necesario
definir ningún idioma al arrancar la misma, a no ser que queramos alterarlo
de forma manual usando la acción cambiarIdioma.do, ya que el navegador
tendrá definido un idioma por defecto y en cada petición será
detectado y tratado de forma automática por struts. Enviando los
mensajes según corresponda.
l  Si configuramos el navegador en un idioma no contemplado por la
aplicación, ésta se mostrará en el idioma por defecto, es decir, mostrando
las etiquetas del archivo ApplicationResources.properties.

@javioliful


Mostrando mensajes variables
l  Más allá de los mensajes de error y otros, podemos mostrar texto plano o
con formato, desacoplado de la presentación en cuanto al idioma se refiere.
Para ello debemos usar las etiquetas personalizadas.
¡  La etiqueta <bean:message>

l  Permite mostrar mensajes desde el archivo de recursos de la aplicación. El
mensaje será el asociado a la clave, indicada en el atributo key.

l  Cualquier JSP


@javioliful


Resultado de la ejecución


@javioliful


Tema 8: Composición de vistas
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 

Introducción
Plantillas con Struts
Composición de vistas con Struts Tiles
Layout
Vista JSP
Resultado de la ejecución


@javioliful


Introducción
l  Un problema común a la hora de mantener un sitio Web suele consiste en
la dificultad de aplicar cambios de diseño a todas las páginas que la
componen, pues muchas veces implica tener que modificar cada una de
estas paginas.
l  La especificación JSP incluye mecanismos para poder reutilizar
fragmentos que pueden incluir en numerosas páginas. Para ello
disponemos de la directiva <@page include="fragmento.jsp">.
l  De esta forma podemos hacer inclusiones de pies de página, encabezados,
zonas laterales de menú, etc.


@javioliful


Introducción
l  De esta manera, cualquier operación de mantenimiento se podrá
realizar en los fragmentos y por lo tanto serán propagados por todas
las páginas afectadas. Pero esto a su vez conlleva un problema: ¿qué
ocurre si se toma la decisión de modificar la ubicación en la página de
uno de los elementos que hemos incluido mediante la directiva
include?. No tenemos más remedio que modificar todas la páginas y
cambiar el lugar donde se realiza el include.
l  Para resolver este problema, debemos introducir un concepto nuevo ya
utilizado en otras tecnologías para el diseño de interfaces de usuario, el de
"template" o plantilla y que no existe en la especificación JSP de J2EE.


@javioliful


Plantillas con Struts
l  Las plantillas definen no sólo los elementos reutilizables si no la
ubicación de los mismos. La idea consiste en especificar de manera
única, el diseño o "layout" de un conjunto de páginas. Esta plantilla sería lo
único que deberíamos cambiar en caso de querer modificar el diseño
común de esa parte de la aplicación.
l  En la plantilla se debe maquetar de manera que montaremos una
composición con los distintos elementos dinámicos de la página. Las
páginas concretas que se mostrarán, se limitarán a referenciar a una cierta
plantilla y asignarán el contenido de las distintas piezas que usa la plantilla
usada (cabecera, menú, pie y contenido).
l  Las vistas, por lo tanto, se compondrán de dos partes: por un lado la
plantilla propiamente dicha (layout) y por otro la página JSP que usará
dicha plantilla, definiendo el contenido al que hacemos referencia cuando
insertemos los distintos tiles. Ésta última será que será invocada por struts
en el proceso de redirección del flujo de la petición.


@javioliful


Composición de vistas con Struts Tiles
l  Una vez comprendido el concepto de plantilla vamos a pasar a ver como
definirlas mediante el uso de Struts Tiles. Afortunadamente no tenemos que
aprender un nuevo lenguaje o tecnología para diseñar las plantillas, ya que
éstas se definen en una JSP.


@javioliful


Layout
l  Echemos un vistazo al código donde hemos diseñado la plantilla principal
(layoutVerUno.jsp).
l  La base del código es fundamentalmente HTML, una tabla que en las
distintas celdas tendrá ubicadas las porciones a modo de tiles (ladrillos).
l  En primer lugar, usaremos la etiqueta <tiles:insert>, con ella daremos
valor a las distintas variables que se definen en la plantilla.
l  En el siguiente código veremos la forma que tendría la página
layoutVerUno.jsp. Podemos observar la ubicación de las distintas porciones
de la página.


@javioliful


Layout
l  layoutVerUno.jsp


@javioliful


Vista JSP
l  Ahora sólo nos queda definir un JSP que haga uso en forma de plantilla
de este 'layout'. En la especificación del 'layout' anterior, utilizamos la
etiqueta <tiles:insert> para especificar un atributo que nos servirá para
indicar ahora en la plantilla cómo insertar el diseño de cada zona. Esta
página será la que será invocada en concepto de vista del caso de uso, en
nuestro caso verUno.jsp, por lo que no habrá que modificar el contenido de
struts-config.xml.
l  En esta página se definen aquellas partes variables que serán
referenciadas en la página "layout", por ejemplo header o copyright, y su
correspondiente relación con las jsp que lo componen, en el caso anterior
header.jsp y coyright.jsp. De la misma forma pueden aparecer
referencias directas a variables, mensajes, títulos, etc.. que actuarán como
si fueran pares de parámetros con su nombre y valor.
l  Veamos el código de esta página prestando especial atención a la etiqueta
page que indicará la plantilla a utilizar (layout).


@javioliful


Vista JSP
l  Veamos el código de esta página prestando especial atención a la etiqueta
page que indicará la plantilla a utilizar (layout).

l  Es importante tener bien construidas las páginas de las que se compone la
vista, ya que un error en alguna de ellas puede ser incómodo de detectar.
Estas páginas actúan como fragmentos de jsp, por lo que no ser requiere
su definición completa. Digamos que sustituyen a la directiva include u
otros mecanismos nativos de jsp.


@javioliful


Vista JSP
l  Ejemplo de contenido, página contentVerUno.jsp


@javioliful


Tema 9: Bibliotecas de etiquetas
¡ 
¡ 
¡ 
¡ 
¡ 
¡ 

Introducción
Uso de una librería de etiquetas
Biblioteca de etiquetas HTML
Biblioteca de etiquetas BEAN
Biblioteca de etiquetas LOGIC
Ejemplo biblioteca LOGIC


@javioliful


Introducción
l  El uso de las bibliotecas de etiquetas separa el código java de las páginas
JSP. Esto nos permite crear páginas jsp que no contengan ni una sola línea
de código java. La lógica es ejecutada por las etiquetas.


@javioliful


l  En los primeros ejemplos del manual, cuando hemos creado la página de
entrada que contenía el formulario de registro, ya hemos utilizado las
bibliotecas de etiquetas. Las librerías deben ser acompañadas de su
correspondiente archivo tld (Tag Library Descriptor) y depende de la
especificación de Servlets/Jsp que usemos podremos usar las etiquetas
propias del Framework de una u otra forma.
l  Recordamos los pasos que debemos seguir:


@javioliful


l  1. Las bibliotecas de etiquetas y sus descriptores deben formar parte de
nuestra aplicación:
¡ 
¡ 
¡ 
¡ 

struts-bean.tld
struts-html.tld
struts-logic.tld
…..

l  Los descriptores .tld encuentran en la carpeta lib del directorio de
instalación de struts o están empaquetadas en los archivos .jar de librerías,
depende de la distribución que se utilice.
l  El código compilado de estas etiquetas se encuentra en el archivo
struts.jar. No hemos de olvidar incorporar este archivo jar dentro del
directorio lib de nuestro WEB-INF.


@javioliful


l  2. Mediante el uso de la directiva taglib, importamos las bibliotecas de
etiquetas a la página jsp. Esto podemos hacerlo de dos maneras,
dependiendo de la especificación de Servlets que usemos.
A.  Referencia al tld (Tag Library Descriptor): usando la uri que referencia los
archivos descriptores de etiquetas .tld. Esto se hará incluyendo la siguiente
definición en el web.xml. Previamente las etiquetas deben estar ubicadas en un
directorio bajo WEB-INF
¡  web.xml

¡  Referencia en nuestra página a la uri en cuestión


@javioliful


B.  Usando especificación 2.3 de Servlet: si usamos la especificación de
Sevlets 2.3, podemos obviar esta configuración (declaración en web.xml)
para usar directamente la uri que corresponde a cada uno de los grupos de
etiquetas personalizadas, delimitados por la definición de un .tld y cuya uri
está definida en el mismo.
¡  Referencia directa en la JSP


@javioliful


l  Se utiliza fundamentalmente para construir formularios de entrada de datos.
Aunque también se utiliza para otras funciones como pueden ser: mostrar
mensajes de error, proporcionar enlaces con reescritura de URL incluyendo
el identificador de sesión, generar código de validación javascript, entre
otras.
l  En la siguiente tabla se muestran algunas de las más utilizadas:


@javioliful




@javioliful


Biblioteca de etiquetas BEAN
l  Proporciona una serie de etiquetas para trabajar con javabeans. Se
recogen en esta tabla los más comunes:


@javioliful


Biblioteca de etiquetas LOGIC
l  Esta librería proporciona mecanismos para la presentación de datos al
usuario.


@javioliful


l  Vamos a ver un ejemplo de utilización de esta última librería.
l  1. Creamos un Action que introduzca una lista como atributo de la petición,
con todos los artículos de la cesta.
l  ConsultaAtculos.java


@javioliful


l  2. Configuramos la acción en el archivo struts-config.xml. Del siguiente
modo:


@javioliful


l  3. Creamos una página jsp a la que nos dirige el forward exito. En esta
página se utilizan las etiquetas de la biblioteca logic para iterar sobre la
coleccion.
¡  Esta lista, si miras el código del punto anterior, se ha introducido como atributo
de la petición. A este atributo hacemos referencia en la etiqueta <logic:present>
para determinar si existe o no tal atributo.
¡  El código de la página jsp es el siguiente:


@javioliful


l  verTodos.jsp


@javioliful


l  El resultado en ejecución:


@javioliful


Aplicaciones web con jakarta struts - Javier Oliver Fulguera

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (7)

Similar a Aplicaciones web con jakarta struts - Javier Oliver Fulguera

Similar a Aplicaciones web con jakarta struts - Javier Oliver Fulguera (20)

Último

Último (20)

Aplicaciones web con jakarta struts - Javier Oliver Fulguera