Manual 2017-I 05 Desarrollo de Aplicaciones Web I (CI) (0265)

Desarrollo de
Aplicaciones Web I
DESARROLLO DE APLICACIONES WEB I 2
CARRERAS PROFESIONALES CIBERTEC

DESARROLLO DE APLICACI ONES WEB I 3
Índice Página
Presentación 5
Red de contenidos 7
Unidad de aprendizaje 1
FRAMEWORK MVC - STRUTS 2
1.1 Tema 1 : Fundamentos 11

1.1.1. : Arquitectura 12
1.1.2. : Configuración básica 19
1.1.3. : Actions 32
1.1.4. : Tag Libraries 36
1.1.5. : Result Types 39
1.1.6. : Interceptores 70
1.1.7. : Internacionalización – I18N 81
1.1.8. : Validaciones 92
1.1.9. : Otros elementos de configuración 103
1.1.10 : Tiles 112
1.2 Tema 2 : Proyecto Plantilla
1.2.1 : Aplicación Web de 3 capas 121
FRAMEWORK DE PERSISTENCIA – MYBATIS
2.1 Tema 3 : Fundamentos 127
2.1.1. : Arquitectura y Configuración 128
2.1.2. : Mappers 148
2.1.3. : XML Mapped Statements 150
2.1.4. : Annotated Mapped Statements 161
2.1.5. : Otras configuraciones 167
2.2 Tema 4 : Proyecto Plantilla 176
2.2.1. : Aplicación Web 176
REPORTES CON JASPER
3.1 Tema 5 : Jasper Reports 189
Diseño e implementación de reportes con

3.1.1. : 190
la herramienta IReport Designer
3.2 Tema 6 : Proyecto Plantilla 229
3.2.1. : Integración de Struts 2 y JasperReport 229
CIBERTEC CARRERAS PROFESIONALES


Presentación
Desarrollo de aplicaciones web I, pertenece a la línea de Programación y Desarrollo

de Aplicaciones. Es un curso de especialidad sólo en la carrera de Computación e
Informática. Permite al estudiante concretizar proyectos informáticos web aplicando
conocimientos previos aprendidos en diferentes cursos y poniendo en práctica la teoría
adquirida. De esta manera, consolida conocimientos de diversos cursos de especialidad.
Es práctico y desarrollado en laboratorio. Se implementarán soluciones web que
utilizarán los Frameworks Struts 2 y MyBatis en forma combinada.
El contenido del manual es de carácter académico y su alcance es servir como

referencia para los ejercicios a realizar durante el curso de acuerdo al sílabo, por lo cual
no cubre a detalle todos los temas/técnicas que se pueden aplicar en los distintos
Frameworks.
El manual ha sido diseñado bajo la modalidad de unidades de aprendizaje, las que se

desarrollan durante semanas determinadas. En cada una de ellas, hallará los logros que
debe alcanzar al final de la unidad; el tema tratado, el cual será ampliamente
desarrollado; y los contenidos que debe desarrollar, es decir, los subtemas. Por último,
encontrará las actividades que deberá desarrollar en cada sesión, que le permitirán
reforzar lo aprendido en la clase.
El curso es eminentemente práctico y se desarrolla íntegramente en laboratorio. En

primer lugar, se inicia con el reconocimiento del patrón Model View Controller (MVC).
Luego, continúa con la presentación del Framework MVC Struts 2. Se profundiza en sus
principales características y componentes. Después, se desarrollan conceptos de
persistencia de datos utilizando, para ello, el Framework MyBatis. Por último, se
concluye con la elaboración de reportes utilizando JasperReports, la herramienta
IReport Designer, para, finalmente, integrarlo en aplicaciones web desarrolladas con
Struts 2.


Red de contenidos
Desarrollo de Aplicaciones Web I
Framework MVC Framework de Reportes

Persistencia
Struts 2 Jasper
MyBatis


UNIDAD
1
FRAMEWORK MVC – STRUTS 2
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al finalizar la unidad, el alumno utilizando el Framework MVC Struts 2
implementa una aplicación web que contenga, en su estructura, el componente
Action, así como las principales etiquetas, librerías y plugins del Framework.
TEMARIO
1.1 Tema 1 : Fundamentos
1.1.1. : Arquitectura
1.1.2. : Configuración básica
1.1.3. : Actions
1.1.4. : Tag Libraries
1.1.5. : Result Types
1.1.6. : Interceptores
1.1.7. : Internacionalización – I18N
1.1.8. : Validaciones
1.1.9. : Otros elementos de configuración
1.1.10 : Tiles
1.2.1 : Aplicación Web de 3 capas
ACTIVIDADES PROPUESTAS
 Los alumnos implementan una aplicación web básica utilizando las

principales características del Framework MVC Struts 2.


1.1 FUNDAMENTOS
Framework open source, desarrollado por Apache Software Foundation, permite a los
desarrolladores crear Aplicaciones Web basadas en MVC. Éste organiza de manera
independiente las capas: Model (Objetos del Modelo de la Aplicación), View (interfaz
con el usuario u otro sistema) y la capa Controller (controlador del flujo de la
aplicación).
PÁGINA OFICIAL
http://struts.apache.org
PRE-REQUISITOS
http://struts.apache.org/primer.html
Versiones
 Struts 1 (2001)
Struts 1 fue el Framework MVC estándar en la construcción de
aplicaciones Java Web por muchos años.
 Struts 2
Struts 2 es un Framework que combina las mejores características de
Struts 1 y WebWork (xWork) simplificando aún más la tarea de los
desarrolladores. Uno de sus objetivos es definir las características base del
Framework en struts-core y todos los demás complementos en plugins
reduciendo, así, las dependencias con terceros.
RELEASE 2.3.X
http://struts.apache.org/release/2.3.x/index.html
RELEASE 2.3.X - GUIAS

http://struts.apache.org/release/2.3.x/docs/guides.html
RELEASES AND VERSION NOTES

http://struts.apache.org/downloads.html
(Descargar el Full Distribution de la versión 2.3.16)

1.1.1 Arquitectura
Se muestra, a continuación, el esquema básico de la arquitectura MVC implementada

en el Framework Struts 2.
a. A través de un navegador, se genera un request.

b. El request es capturada por el Controller, el cual está implementado con
Servlet Filters e Interceptors.
c. El Controller delega el procesamiento a un componente del Modelo
llamado Action.
d. Durante la ejecución del Action, regularmente, se invocan componentes de
negocio y datos; se accede y/o manipula objetos del modelo y scopes, como
sesión, contexto o request. Al finalizar, se retornará un resultado.
e. Según el objeto Result indicado por el Action, el View realizará el
renderizado del contenido a mostrar al cliente, por ejemplo HTML, imágenes,
PDF, etc.
Una característica típica del View de Struts 2 es el uso de unos componentes

especiales denominados Results. Éstos normalmente son representados por una
página JSP; sin embargo, pueden constituir flujos de bytes, objetos del Framework
Tiles, Jasper, etc.

El ciclo de vida, en Struts 2, funciona básicamente de la siguiente manera:
FUENTE DE IMAGEN:
http://struts.apache.org/release/2.3.x/docs/big-picture.html
a. El Servlet Container (Tomcat) recibe un request de tipo HttpServletRequest.

b. Se ejecuta una serie de Servlet Filters, por ejemplo el filtro
StrutsPrepareAndExecuteFilter, el cual maneja las fases de preparación y
ejecución de Struts 2.
c. Dicho filtro consultará al ActionMapper el tipo de componente a invocar.
Si se trata de un Action, el filtro delegará el request al ActionProxy.
d. El ActionProxy determinará el Action a invocar sobre la base de la
configuración de Struts realizada en la aplicación. Luego, creará un
ActionInvocation, componente responsable de ejecutar los Interceptors
asociados a dicho Action, en este punto solo la parte asociada al Request y,
finalmente, el método del Action que corresponda.
e. El método invocado del Action se ejecutará pudiendo instanciar y/o utilizar
diversos objetos de negocio para concretar la tarea solicitada. Al finalizar la
ejecución, dicho método retornará un resultado.

f. El ActionInvocation determinará cuál es el Result asociado al retorno del

Action, (según la configuración de struts) y solicitará su ejecución.
g. Sobre la base del Result y su respectivo Result Type, se realizará el
renderizado del contenido a mostrar al cliente. Los Result, en su mayoría,
tienen asociados templates JSP. Los templates pueden hacer uso de Tags
para generar contenidos.
h. Se ejecutarán nuevamente los Interceptors, pero solo la parte asociada al
response (en caso lo hubieren).
i. Finalmente, se mostrará el resultado al cliente.

LABORATORIO 1
Se revisarán los proyectos Aplicación_01 y struts2-blank.
1.1.1.1 Componentes principales
a. Filtros
Los filtros son el punto de partida del procesamiento de un HttpServletRequest

generado desde un cliente. Se tiene lo siguiente:
o FilterDispatcher
 Ejecuta métodos de preparación (de estar implementado) y
procesamiento en Action.
 Limpia Action Context.
 Asegura disponibilidad de contenido estático (css, js)
 Este filtro tiene estado Deprecated y fue utilizado hasta la
versión 2.1.2
o StrutsPrepareAndExecuteFilter
 Prepara y ejecuta el procesamiento solicitado.
 Se utilizar cuando no se requieren filtros adicionales para
uso de plugins que requieran acceder al Action Context, por
ejemplo Sitemesh.
 Se utiliza a partir de la versión 2.1.3, en reemplazo del
FilterDispatcher.
o StrutsPrepareFilter
 Prepara el procesamiento solicitado.
 Usa interceptor “prepare” que ejecuta método prepare() de
Action en caso se implemente interfaz Preparable.
 Se utiliza a partir de la versión 2.1.3.
o StrutsExecuteFilter
 Ejecuta el procesamiento solicitado invocando un método del
Action.
 Requiere que, previamente, se haya ejecutado el filtro
StrutsPrepareFilter.
b. Interceptores
Los interceptores son Clases que actúan de manera similar a los ServletFilters, pues
se encargan de interceptar los request enviados a un Action ejecutando lógica común
en las aplicaciones, por ejemplo validaciones de campos, i18n, manejo de
excepciones, carga de archivos, uso de token, logging, etc.
Su ejecución se da antes y después de ejecutar el método de procesamiento de un

Action.
Permiten al desarrollador encapsular funcionalidad común y reutilizable que se pueda

usar en uno o más Actions.
Struts 2 tiene una serie de Interceptors implementados para su uso en el desarrollo,

los cuales tienen un orden de ejecución predefinido. Sin embargo, se puede

personalizar dicho orden e, inclusive, definir nuevos Interceptors según la necesidad

del aplicativo.
REFERENCIA
http://struts.apache.org/release/2.3.x/docs/interceptors.html
c. Action
Action es una Clase de Java que tiene implementado uno o más métodos de
procesamiento (típicamente uno por cada request), para lo cual recibe parámetros y/o
devuelve datos del modelo, e invoca componentes de negocio. Al finalizar la ejecución,
retorna un String que representa un objeto Result.
d. Results
Results indica qué recurso debe invocarse, por ejemplo JSP, Freemarker, Velocity,
etc; de modo que se genere la vista con la respuesta al cliente.
El Framework provee diferentes Result-Types nativos que implementan la interfaz

Result; asimismo, permite definir nuevos Result-Types para la integración con plugins
externos.
REFERENCIA
http://struts.apache.org/release/2.3.x/docs/result-types.html
e. Tags y Templates
Struts tiene definidos Tags que permiten generar contenido estático/dinámico, así
como manipular/evaluar objetos en memoria.
Los templates pueden hacer uso de uno o más Tags siempre que lo soporte.
REFERENCIA
http://struts.apache.org/release/2.3.x/docs/tag-developers-guide.html
f. Action Proxy
Action Proxy obtiene instancia del Action y la información del método a ejecutar. Al
utilizar el ActionInvocation, se encapsula la ejecución de un request.
g. Action Invocation
Action Invocation determina cómo se ejecutará el Action invocado por el request

ejecutando secuencialmente uno a uno cada Interceptor presente en su pila, según el
orden que corresponda: el Action y el Result.
REFERENCIA
http://struts.apache.org/release/2.3.x/xwork-core/apidocs/
http://struts.apache.org/release/2.3.x/struts2-core/apidocs/

1.1.1.2 Componentes y Lenguajes de Soporte
a. Action Context
Action Context es el contexto en el cual se ejecuta el Action, es decir, es la zona de

memoria donde se almacenan los objetos necesarios para el procesamiento del
request, por ejemplo parámetros, sesión, application, value stack, etc.
Dicho contexto es representado por una Clase del mismo nombre “ActionContext”
que se instancia ante cada request. El ActionContext es ThreadSafe, pues utiliza la
Clase ThreadLocal, es decir, su instancia es única por cada hilo de ejecución.
El acceso a dicho objeto se puede dar en Clases Action con la siguiente instrucción:
ActionContext.getContext()
b. Value Stack
Value Stack es parte del ActionContext y, dentro de él, reside la instancia del Action
que está en ejecución. Se le conoce como pila, pues puede almacenar objetos en el
siguiente orden:
Objetos de apoyo al renderizar JSP, por

Objetos Temporales
ejemplo al recorrer una colección
Objetos del Modelo Cuando Action es de tipo Model Driven
Action ejecutado y todas sus variables.

Objeto Action
Comúnmente es el primero en la pila.
Referidos a Scopes tales como request,

Otros Objetos
session, application
El acceso a dichos objetos se puede dar según lo siguiente:
 En Clases Action, con la siguiente instrucción:
ActionContext.getContext().getValueStack()
 En Templates, al utilizar Tags de Struts y/o el lenguaje de

expresiones OGNL.
Al invocar un objeto del Value Stack, Struts tomará la primera ocurrencia que
encuentre, por lo cual, si hay dos objetos con el mismo nombre en diferentes niveles,
el Framework puede tomar un objeto incorrecto. Por ello, es importante conocer y
tener en cuenta la profundidad en que están colocados los objetos en la pila para, de
ser necesario, acceder directamente a ellos indicando en la expresión dicha
profundidad.

c. OGNL
El Object-Grap Navigation Language es un lenguaje de Expresiones que, en Struts

2, es utilizado para referenciar y manipular objetos del Value Stack. Para ello, Struts
2 tiene definido un Mapa de ActionContext que consiste en lo siguiente:
 Root: Para acceder directamente a variables de Action.
 Objects: Para acceder a objetos que no están en el Root por

ejemplo application, session, request, parameters, attributes. Para
cualquiera de ellos, OGNL exige el uso del signo “#” como prefijo
seguido del scope donde se encuentre el objeto a referenciar, por
ejemplo:
- #session.username
- #application.estados
- #attr.indice

1.1.2 Configuración Básica
Los componentes de Struts se configuran en archivos XML o con Anotaciones.
Para la configuración en archivos XML, se tiene lo siguiente:
a. Web Deployment Descriptor: web.xml
 Filtros
 TLD (no es requerido)
REFERENCIA
http://struts.apache.org/release/2.3.x/docs/webxml.html
b. Archivo de Configuración Base: struts-default.xml
Contiene configuración, por defecto, de componentes de Struts 2(result types,

interceptors, packages, etc) y de ambiente de ejecución (puerto de ejecución,
activación de modo depuración, temas de diseño, recarga automática de
configuraciones al realizar cambio en archivos XML, etc). Incluso, en el archivo jar de
struts del marco de trabajo, se puede heredar en los packages de Struts.xml.
REFERENCIA
http://struts.apache.org/release/2.3.x/docs/struts-defaultxml.html
c. Archivo de Configuración Properties: struts.properties
Define propiedades para personalizar la configuración por defecto.

Su equivalente es el uso de Constantes en archivos XML.
REFERENCIA
http://struts.apache.org/release/2.3.x/docs/strutsproperties.html
d. Archivo de configuración de Struts: Struts.xml (default requerido)
 Elementos
a. Bean
Para manejo de IoC de objetos principales del marco de trabajo
Struts 2, por ejemplo ActionMappers.
b. Constante
Para personalizar la configuración base del Framework.
c. Package
Agrupa elementos que gestionan el Request, que son los siguientes:
 Interceptors
 Actions
 Result Types
 Global Exceptions
 Global Results
 Default Action
 Default Interceptor stack

Los elementos definidos, en un package, tienen la característica de

compartir atributos comunes, por ejemplo un grupo de interceptors,
namespaces, result types, etc.
Principales ventajas:
 Reutilización de configuración
 Modularización de la aplicación
d. Include
Permite incluir archivos de configuración adicionales que cumplan
con el mismo formato de Strust.xml. Se manejan varios archivos de
configuración para organizar diferentes módulos de una aplicación.

LABORATORIO 2
Se implementarán, desde cero, una primera aplicación con Struts 2.
Objetivos: Comprender la configuración base de un proyecto web con Struts 2
Consideraciones antes de iniciar:
 Solo se implementará la capa de presentación.

 Descargar de moodle el archivo recursos.zip y descomprimirlo.
a. Prototipos:
b. Pasos a seguir:
1. Crear Dynamic Web Project

Siga los pasos del Wizard considerando los valores mostrados en las imágenes:

Estructura inicial del proyecto:
2. Añadir al Proyecto las librerías (jars) de Struts 2.

Copiar los jars dentro de la carpeta WebContent/WEB-INF/lib.
3. Realizar la configuración básica de Struts 2 en el proyecto.
Va a configurar, en el archivo web,xml, el filtro

org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter, según:

Ahora, va a crear el archivo de configuración de struts:
Para ello, cree el archivo Strust.xml dentro del Source Folder.
Luego, añada el siguiente contenido base:
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE struts PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 2.3//EN"
"http://struts.apache.org/dtds/struts-2.3.dtd">
<struts>
<package name="demo" extends="struts-default">
</package>
</struts>

4. Diseñe las siguientes páginas:
Formulario.jsp
Resultado.jsp

5. Cree la Clase Action que atenderá request del formulario.
Cree, dentro de paquete action, la Clase VendedorAction, según:
Entonces:

6. Defina, en el Action, variables de entrada.
Si observa la página Formulario.jsp en el punto 4, identificará que hay un único

campo de entrada. Por ello:
Es importante tener en cuenta que el nombre de la variable debe ser el mismo al

nombre del campo en el formulario del JSP.
Dado que son variables que recibirán valores desde el formulario, se debe definir
método setter por cada una de ellas.
7. Defina, en el Action, métodos de procesamiento del request:
Se le pone el nombre execute, dado que es el método default que se ejecuta en un

Action.
8. Defina, en el Action variables de salida.
Si observa la página Resultado.jsp en el punto 4, identificará que hay dos campos de

salida. Por ello:

Dado que son variables cuyos valores se utilizarán en la vista, se debe definir método
getter por cada una de ellas.
9. Configure el Action: Action Mapping
En el archivo Strust.xml, configure el Action dentro del package “demo”, según:
Strust.xml
10. Conecte las páginas con el Action.
Para que el formulario invoque al Action, debe especificar, en el atributo action del
form, el nombre del ActionMapping:
Formulario.jsp
Para que se muestre la página Resultado.jsp, debe indicarlo en uno de los results del
Action Mapping:

Strust.xml
11. Valores dinámicos en Respuesta
En la página Resultado.jsp, debe mostrar los valores de las variables de salida del
Action.
Para poder acceder a dichas variables desde el JSP, debe utilizar el tag <s:property>,
según lo subrayado:
Resultado.jsp
12. Finalmente, para poder realizar la prueba, no olvide definir el welcome file
en web.xml.
13. Pruebe la aplicación.
14. Ejemplo complementario:
 Integración con servicios

Para obtener la cantidad de ofertas realizadas de un Vendedor, según el

DNI enviado, va a simular un servicio de negocio (sin uso de capa
persistencia). Para ello, cree, en el paquete service, lo siguiente:
Ahora, va a invocarlo desde el método execute del Action:
VendedorAction
Se añadieron las líneas 27 y 28.
 Configuración logging con Log4j
En el Source Folder, cree el archivo log4j.properties y añada el siguiente

contenido:
log4j.rootLogger=INFO, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
# Pattern to output the caller's file name and line number.

log4j.appender.stdout.layout.ConversionPattern=[PIT %p] %-5m
%d{dd/MM/yyyy HH:MM:ss} %n
log4j.logger.com.opensymphony.xwork2=INFO
log4j.logger.org.apache.struts2=INFO

1.1.3 Actions
Actions son Clases principales que utiliza el Framework. En ellas, se implementa la

lógica de procesamiento necesaria para atender un request, soporte para transferir
datos entre templates y modelo, así como determinar la vista a retornar al cliente.
Su configuración se realiza en el archivo Strust.xml y se denomina ActionMapping.

En la siguiente imagen, se observa un extracto del archivo Strust.xml con un
ActionMapping configurado dentro del package:
Una Clase de tipo Action puede contener lo siguiente:
 Variables globales declaradas para almacenar valores de parámetros

enviados en el request. Se requiere implementar método setter por cada
variable.
 Uno o más métodos de procesamiento sin argumentos, según:
Por defecto, el Framework ejecutará un método con nombre execute. Sin embargo,
puede personalizar ello al indicar, en el ActionMapping, el nombre del método a
ejecutar.
Cada método ejecutará lógica para atender el request apoyándose, para ellos, en
servicios de negocio u otro tipo de componentes. Luego, sobre la base del resultado
del proceso, deberá retornar un String que referencie a uno de los Results
configurados en el ActionMapping.

Por ejemplo:
Los Action que hereden ActionSupport pueden hacer uso de los métodos
addActionMessage() y addActionError() para definir mensajes informativos y de
error respectivamente. Dichos mensajes podrán ser mostrados en las páginas
haciendo uso de tags del mismo nombre (ver punto 1.1.4)
 Variables globales que almacenan valores a mostrar en el resultado. Se

requiere implementar método getter por cada variable.
A modo de repaso, revise lo hecho en el laboratorio 2:
 Al enviar request desde un browser:

 Al mostrar resultado del request con valores obtenidos desde variables del
Action:
Implementación
Se tienen 3 alternativas:
a. Clase POJO
No hereda Clases ni implementa Interfaz. No soporta toda la funcionalidad
brindada por el Framework Struts.
b. Clase que implementa interfaz Action

La interfaz Action define constantes genéricas para la vista y el método
execute(), el cual se ejecuta por default ante cada invocación.
c. Clase que hereda Clase ActionSupport

La Clase ActionSupport implementa la interfaz Action y provee
funcionalidad extra que le permita a los Interceptors manipular el Action a
invocar, por ejemplo temas de Validación y/o I18N.
Nota: En el laboratorio 2, ha aplicado la primera alternativa.
Configuración

a. XML: Se realiza en el archivo Strust.xml a través de Action Mappings

declarados dentro de un package de struts
Ejemplo:
Donde, el elemento action consta de atributos y elementos:
 name: alias que identifica el Action.

 class: para indicar la ruta del Action “paquete1.NombreClase”. Por
defecto, se ejecuta la Clase ActionSupport.
 method: indica nombre de método a ejecutar. Por defecto, se ejecuta el
método “execute()” del Action.
 result: Define recurso que generará la vista. En un ActionMapping, se
pueden definir múltiples Results, según la funcionalidad requerida. Sin
embargo, solo se puede retornar un result por cada request.
b. Anotaciones
Alternativa al uso de XML. Requiere el uso del Convention Plugin.
REFERENCIA
http://struts.apache.org/release/2.3.x/docs/annotations.html
Ejecución
Un Action se invoca a través del alias definido en el ActionMapping, por ejemplo

“http://localhost/demo/alias.action”, donde “.action” es la extensión por defecto para
todo Action.
Si sigue el ejemplo anterior, la URL será

http://localhost:8080/Aplicacion_02/registrarVendedor.action

1.1.4 Tag Libraries
Struts provee Tag Libraries que permiten generar contenido estático/dinámico, así
como manipular/evaluar objetos en memoria. Su uso se da en el View, ya sea en
tecnologías JSP, Velocity o Freemarker.
REFERENCIA
http://struts.apache.org/release/2.3.x/docs/tag-developers-guide.html.
Para utilizar tags de Struts, en los JSP, realice lo siguiente:
a. Importe el tag library con la siguiente directiva:
<%@taglib prefix="s" uri="/struts-tags" %>
b. Haga uso del prefijo “s” para seleccionar los tags que se requieran, por
ejemplo para generar un formulario con una caja de texto y un botón se
tiene lo siguiente:
<s:form action="vendedorAction">
<s:textfield name="dni" label="DNI" />
<s:submit />
</s:form>
Observe, en el atributo name del textfield, el uso de OGNL para acceder a una variable
de un Action.
Struts 2 cuenta con temas de diseño preconfigurados que son los siguientes:
 Simple
 Xhtml (default)
 Ajax
Según el tema configurado en la aplicación, al invocar un template (JSP), el

Framework renderizará la página autogenerando el código HTML de ser el caso.
Asimismo, puede definir nuevos temas de diseño.
Por ejemplo, un diseño similar al realizado en el Formulario.jsp del laboratorio 2 se

puede realizar con tags de struts de la siguiente manera:
Dado que por default está configurado el tema Xhtml, el formulario creado con tags de
struts en el punto anterior se renderizará de la siguiente manera:

A modo de ejemplo, vea el resultado del uso de tags el tema Xhtml :

Según lo visto hasta el momento, ¿cómo se relacionan los componentes?

1.1.5 Result Types
El rol de la vista lo representa el Result que se configura con la etiqueta <result> en

Strust.xml:
<result name="exito">/paginas/resultado.jsp</result>
Cada Result definido en un Action tendrá asociado una implementación que puede
ser Dispatcher, Redirect, Stream, Velocity, entre otras. Dicha implementación viene a
ser lo que se conoce como Result Type. En el ejemplo, el Result Type asociado es
el Dispatcher por ser el default. Si se quiere generar otro tipo de resultado, deberá
indicarlo con el atributo type, según:
<result name="exito" type="redirect">/resultado.jsp</result>
Notas:
 Si un result no tiene definido name, por defecto su name es ”success”.

 Si un result no tiene definido type, por defecto su type es ”dispatcher”.
Algunos ejemplos de Result Types predefinidos son los siguientes:
Estos están declarados en el archivo struts-default.xml, según:
En caso ninguno de los Result Types predefinidos sea suficiente para generar la
vista, también, tiene la opción de crear ResultTypes personalizados. Para ello,
deberá crear una Clase que implemente la interfaz
com.opensymphony.xwork2.Result y registrarlo en los packages de Strust.xml que
lo requieran con el elemento <result-types>
Por ejemplo:

REFERENCIA
http://struts.apache.org/release/2.3.x/docs/result-types.html

LABORATORIO 3
Se va a implementar la funcionalidad del Registro de un Empleado.
Objetivo: Implementar la capa de presentación con Struts 2.
 La aplicación a importar es una plantilla base con algunos componentes

implementados, por ejemplo las capas de negocio y persistencia, así
como los objetos del modelo (Cargo y Empleado)
 Las páginas en adelante siempre deben estar ubicadas dentro de la
carpeta WEB-INF.
 Script de Base de datos será entregado junto con proyecto
Aplicación_03_inicio.war
a. Prototipos:

b. Pasos a seguir:
1. Importe el proyecto Aplicación_03_inicio.war
2. Revise y entienda la configuración inicial.
3. Diseñe las páginas

Principal.jsp

Nuevo.jsp
Resultado.jsp

4. Cree la Clase Action que atenderá request del formulario.
Cree, dentro de paquete action, la Clase EmpleadoAction, según:
En este ejemplo, las variables de entrada y/o salida están encapsuladas dentro del
objeto Empleado, es por ello que se declara dicho objeto en la línea 14.
En el método que procesa el request, observe que no se llama execute sino registrar,
lo cual es válido. Sin embargo, se debe indicar el nombre de dicho método en el
Action Mapping para que el Framework lo ejecute ante un request.
En el método registrarse, se invoca al servicio que realizará el registro del empleado

en base de datos.
En el método registrar, observe, en la línea 32, el uso del método

addActionMessage, el cual sirve para añadir mensajes informativos al ValueStack, de
modo que se pueda mostrar en el Result. Para ello, en los templates, se hace usp del
tag actionMessage (ver Resultado.jsp)

El Action hereda la Clase ActionSupport, lo cual será el estándar en adelante para el

curso.
5. Configure el Action: Action Mappings.
Strust.xml
Se han añadido dos ActionMappings que referencian a la misma Clase Action. El

primero de ellos sirve solo para redireccionar a la página Nuevo.jsp y el segundo
ejecuta el método registrar del Action.
Nótese que los results, en general, no tienen name, eso quiere decir que por defecto
su name=success,
Para que el enlace, en la página Principal.jsp, invoque al Action, debe especificar, en

el atributo href, el nombre del ActionMapping, según:
Principal.jsp

Nuevo.jsp
Asimismo, en cada campo, debe especificar, en el atributo name, en que variable del
Action se guardará el valor ingresado por el usuario.
 Importe el proyecto Aplicación_03_intermedio.war
 Uso de Constantes

 Carga de listados para los combos del formulario
Los listados que requiere un formulario pueden ser precargados utilizando

diferentes técnicas, en diferentes momentos y en un scope determinado,
por ejemplo con ServletContextListeners al iniciar sesión, por cada request,
etc.
En el caso de Struts 2, una opción que ofrece es el método prepare, para

lo cual el Action debe implementar la interfaz
com.opensymphony.xwork2.Preparable. En el ejemplo, puede
implementar el método para cargar listados estáticos, como género y
estado civil, así como listados dinámicos obtenidos desde una fuente de
datos, por ejemplo el listado de Cargos.

EmpleadoAction
En la línea 19, se indica la implementación de la Interfaz Preparable.
En la línea 64, se ubica el método prepare, que inicializa los listados

mencionados. Cada listado es declarado como variable global (lineas 25 a
27) con su respectivo método getter.
Dado que se tiene listados en memoria, debe realizar los cambios

necesarios en el formulario, según:

Nuevo.jsp
En el caso de géneros y estados civiles, dado que son Maps, basta con
indicarlos en el atributo list de cada campo.
En el caso de cargos, dado que es un java bean, además del atributo list,
se debe utilizar los atributos listKey y listValue para especificar la variable
desde donde se obtendrá el valor del código y descripción a mostrar en la
lista.

LABORATORIO 4
Se va a implementar el Log In y Log Out en la aplicación del laboratorio 3.

como los objetos del modelo (Usuario).
a. Prototipos:

b. Pasos a seguir:
1. Importe el proyecto Aplicación_04_inicio.war.

Login.jsp
Principal.jsp

Se han añadido las líneas 12 y 13 para contenido dinámico, así como enlace para
cerrar sesión en la línea 21.
4. Cree la Clase Action que atenderá request del formulario de Login.jsp.
Cree, dentro del paquete action, la Clase UsuarioAction, según:
En este ejemplo, las variables de entrada y/o salida están encapsuladas dentro del
objeto Usuario, es por ello que se declara dicho objeto en la línea 21.
En el método login, se invoca al servicio que realizará la validación de credenciales.

Se tienen dos escenarios:
 Autenticación conforme: el servicio devolverá la fecha del último

acceso del usuario, se guardará en Sesión la cuenta del usuario, se
añadirá mensaje informativo usando el método addActionMessage y
se redireccionará a la página principal del sistema. Vea líneas 37 a 43.
 Credenciales incorrectas: el servicio devolverá objeto nulo, se añadirá
mensaje de error usando el método addActionError y se retornará a la
página del login. Vea líneas 44 a 47.

En el método logout, primero, se obtendrá la sesión (línea 54) para, posteriormente,

invalidarla (línea 56) y, finalmente, retornar a la página de login.
5. Configure el Action: Action Mappings.
Strust.xml
Se han añadido dos ActionMappings que referencian a la misma Clase Action. El

primero de ellos sirve para ejecutar el método login, para lo cual tiene dos posible
Resultados (result). El segundo ejecuta el método logout del Action.
Login.jsp
Asimismo, en cada campo, debe especificar, en el atributo name, la variable del

Action donde se guardará el valor ingresado por el usuario.
Se ha añadido, también, el tag actionError para mostrar, en caso hubieren, los

mensajes de error definidos en el Action.

Principal.jsp
Se han realizado los ajustes en las líneas 12, 13 y 21, según:
En la línea 12, se observa el uso de OGNL para acceder al SessionScope haciendo

uso del prefijo #.
 Importe el proyecto Aplicación_04_intermedio.war.
 Interfaces Aware
Estas son utilizadas para acceder, a través de un objeto Map, a los scopes
que maneja la aplicación:
Scope Interface
request ServletRequestAware
response ServletResponseAware
sesión SessionAware
contexto ServletContextAware
En el proyecto, ha obtenido la sesión de usuario utilizando el objeto

ActionContext, lo cual es válido. Sin embargo, para un mayor
desacoplamiento de los scope, en el código, va a hacer uso del
SessionAware:

Para ello, se debe implementar dicha interfaz en el Action, definir una

variable global de tipo SessionMap y generarle un método setter (lineas
15, 21 y 23 respectivamente).
Luego de ello, puede acceder a la sesión directamente desde cualquier

método del Action, por ejemplo ver las líneas 42 y 54.

 Uso de ResultType redirectAction
En el ActionMapping logoutUsuario, se observa que el único result

referencia al Login.jsp.
Dado que no se requiere reenviar el request, podría definirlo como

type=redirect, sin embargo, dado que ya existe un ActionMapping
genérico llamado inicio, puede configurarlo para que lo referencie
directamente según lo siguiente:
Strust.xml
 Estilos CSS predefinidos de Struts
Al usar el tag <s:head> en las páginas jsp, se genera referencia a hojas de

estilo que se aplican a los componentes visuales, según el tema utilizado.
En Login.jsp, se ha aplicado dicho tag (línea 8) obteniendo este resultado:
Si revisa el código fuente de la página, encontrará esta referencia:
<link rel="stylesheet" href="/Aplicacion_04_final/struts/xhtml/styles.css"

type="text/css"/>
9. Ejercicio propuesto de aplicación
Implemente, en un nuevo proyecto, la funcionalidad de registro de sede

según siguientes prototipos:

LABORATORIO 5
Se va a implementar una nueva funcionalidad al proyecto base: Mantenimiento de

Vendedores.

como los objetos del modelo (Vendedor y Distrito).
 Para el registro y actualización se utilizará un único jsp.
a. Prototipos:

b. Pasos a seguir:

Principal.jsp
Se han añadido las líneas 20 y 22 para enlace al mantenimiento de Vendedores.

Listado.jsp
Edicion.jsp

Detalle.jsp
4. Cree la Clase Action que atenderá el CRUD de Vendedor.
Cree, dentro de paquete action, la Clase VendedorAction, según:


En este ejemplo, las variables de entrada y/o salida de formulario están encapsuladas
dentro del objeto Vendedor, es por ello que se declara dicho objeto en la línea 24.
Para almacenar en memoria el listado de Vendedores, se ha declarado un List en la

línea 23.
Asimismo, se han declarado los listados de combos (género y distrito) que se

inicializan en el método prepare.
Se han implementado 5 métodos para atender el CRUD, todos ellos invocan a un

método del servicio según corresponda y devuelven result.

5. Configuración del Action: Action Mappings
Strust.xml
Se han añadido siete ActionMappings de los cuales 6 referencian a la Clase

VendedorAction y solo 5 ejecutan un método implementado en dicha Clase.
Principal.jsp
En la línea 22, se enlaza el link a un ActionMapping, el cual redirije a la pantalla de

busqueda de vendedores.

Listado.jsp
Se define el formulario de búsqueda y el enlace hacia el formulario de edición.
En la línea 28, se añada el tag de estructura de control if, el cual evalúa si el listado de
vendedores tiene registros o no. Si es así, procede a ejecutar su contenido.

En la línea 40, se hace uso del tag iterator, el cual permite recorrer el listado y
acceder a los objetos.
En las líneas 42 a 44 se hace uso del tag property para acceder a las propiedades
del objeto Vendedor, esto por cada iteración.
En las últimas 3 columnas de las tablas, se realiza lo siguiente:
 Definir un URL con paramétros: Se define actionMapping a invocar

enviándole, como parámetro, el código del vendedor seleccionado.
 Se crea un enlace utilizando el tag a, el cual referencia al URL utilizando
OGNL.
Edicion.jsp
Cada campo referencia a un atributo del bean Vendedor.
Se ha declarado un campo oculto, para poder identificar, según valor del código, si se
trata de una actualización o nuevo registro.

Detalle.jsp
Se muestran los valores del registro seleccionado utilizando el tag property.
Al utilizar como base el proyecto “Aplicación_05_final.war”, añada la

funcionalidad de mantenimiento de las tablas Empleado y Usuario.

1.1.6 Interceptores
Interceptores son la base del Framework Struts 2 y consiste en Clases Java que
actúan de manera similar a los ServletFilters, pues se encargan de interceptar los
request enviadas a un Action ejecutando cierta lógica común en las aplicaciones, por
ejemplo validaciones, i18n, manejo de excepciones, etc;.
Su ejecución se da antes y después de ejecutar el método de procesamiento de un

Action.
Por ejemplo:
En la imagen, se observa que el Action tiene configurado 6 Interceptores, que se

ejecutarán en orden secuencial según lo siguiente:
 Durante el request, el conjunto de interceptors se ejecutará empezando por

Exception hasta Params,
 Luego, se ejecutará el método de procesamiento del Action
 Finalmente, se ejecutará nuevamente el conjunto de interceptors pero a la
inversa, es decir desde Params hasta Exception.

Struts 2 tiene predefinido un conjunto de Interceptors e Interceptor-Stacks (pilas),

estos últimos agrupan uno o más Interceptores definiendo su orden de ejecución.
En el archivo struts-default.xml, puede observar el listado de Interceptores e

Interceptor-Stacks declarado en el package struts- default. Allí, encontrará un
Interceptor-Stack llamado defaultStack:
Dicho Interceptor-Stack está configurado como default, por lo cual se ejecutará en los
demás packages:
Sin embargo, en la aplicación, puede definir nuevos Interceptor-Stacks para ser

utilizado en uno o más packages e inclusive definir nuevos Interceptors según la
necesidad del aplicativo.
Por ejemplo:
a. Interceptor-Stack que agrupa interceptors predefinidos:
b. Nuevos Interceptors (*)

c. Interceptor-Stack que agrupa interceptors predefinidos y

personalizados:
(*)Para ello, primero, se debe crear una Clase Java que implemente métodos de la
Interfaz com.opensymphony.xwork2.interceptor.Interceptor.
Por ejemplo:
El método invoke() invocará al siguiente Interceptor en el Stack o al Action en caso

no hayan más Interceptors.

Si quiere que un Interceptor-Stack diferente al default se aplique en un package de

Strust.xml, debe utilizar el elemento default-interceptor-ref dentro del package ó,
si se requiere que se aplique un Interceptor-Stack específicamente a un
ActionMapping, utilice el elemento interceptor-ref
Por ejemplo:
a. default-interceptor-ref dentro de package
b. interceptor-ref dentro de ActionMapping
REFERENCIA
http://struts.apache.org/release/2.3.x/docs/interceptors.html

LABORATORIO 6
Se va a configurar interceptores sobre el proyecto base.
a. Prototipos:
No se modificara la funcionalidad actual del sistema.
b. Pasos a seguir:
2. Uso de parámetro ExcludeMethods
Despliegue la aplicación, ingrese al módulo de mantenimiento de Vendedor y verifique

si se ejecuta el método prepare del Action ante cada request.
¿A qué se debe? Esto es debido a que el defaultStack incluye el interceptor

“prepare”, responsable de la ejecución de dicho método.
¿Se puede optimizar el comportamiento del sistema?
Para evitar que el método prepare se ejecute siempre que se invoca al Action, puede
configurar los métodos que deben ser excluídos del PrepareInterceptor.
Primero, identifique qué métodos no requieren que se aplique el PrepareInterceptor:
 VendedorAction
 Buscar
 Eliminar
 editar
 EmpleadoAction
 registrar
Ahora que los tiene identificado, proceda a reconfigurar el defaultStack dentro del
package demo, según:
Strust.xml
Observe que ha definido un nuevo interceptor stack “pitStack” que referencia al

defaultStack, con la diferencia que se ha incluido un parámetro que indica los métodos
a excluir del PrepareInterceptor.

Para que todos los ActionMapping hagan uso del nuevo stack, debe añadir lo
siguiente:
Finalmente, pruebe la aplicación y verifique la ejecución del método prepare en los

Actions.
¿Qué otros interceptors soportan el parámetro “excludeMethods”?

¿Para qué sirve el parámetro “excludeParams”?
3. Uso del interceptor-stack paramsPrepareParamsStack
Este interceptor-stack también viene predefinido en el struts-default. Es similar al

defaultStack. Sin embargo, uno de las principales diferencias es que antes del
ejecutar el método prepare guarda en el Action los parámetros del request.
Esto es muy útil, por ejemplo, cuando se requieren cargar objetos a mostrar en un
formulario de edición para actualizar los datos.
En el proyecto base, dentro del mantenimiento de Vendedor, tiene la funcionalidad de

actualización que inicia al dar clic en el enlace “A”.
En la versión actual, dicho enlace invoca un ActionMapping, lo cual funciona, pero

puede optimizarlo aprovechando las bondades de Struts2.

Para ello, va a definir el paramsPrepareParamsStack únicamente al ActionMapping

que se invoca al dar clic en el enlace “A”, pues es el único caso, en el proyecto, donde
aprovechará sus características.
Strust.xml
También, añadirá, en el método prepare del Action, una estructura de control if para
que efectué la carga del vendedor si y solo si el código del mismo fue enviado desde el
cliente y almacenado en el atributo vendedor.codigo antes de ejecutar este método.
VendedorAction
Asimismo, puede borrar el método cargar del mismo Action, debido a que ya no será
utilizado por la aplicación.

En resumen, observe el gráfico comparativo con el antes y despues del cambio:
Finalmente, pruebe la aplicación y verifique que se ejecute correctamente lo

configurado.
4. Revise que el interceptor-stack definido para Action Mappings solo rutea a

templates.
Observe los siguientes Action Mappings
Strust.xml

Si analiza un poco, se dará cuenta que no requiere aplicar todos los interceptores del
pitStack, por lo cual puede definir un interceptor-stack más básico, por ejemplo el
i18nStack, que también viene predefinido en struts-default:
Vuelva a probar la aplicación.
 Importar proyecto Aplicación_06_intermedio.war
 Caso: Se requiere guardar en los logs el tiempo de ejecución de cada

Action ejecutado.
Solución: Implementar un Custom Interceptor
a. Cree, en el paquete interceptor, la Clase CronometroInterceptor

que implemente la interfaz
com.opensymphony.xwork2.interceptor.Interceptor

Vea lo implementado en el método intercept:
 Durante request
- Línea 23: se obtiene tiempo de inicio.
- Línea 25 y 26: se obtiene nombre de ActionMapping y
Action
 Línea 28: se propaga la ejecución al siguiente interceptor del

stack.
 Durante response
- Línea 31: se obtiene tiempo en que finaliza ejecución.
- Línea 32: se obtiene tiempo transcurrido
- Línea 33: se genera log.

b. Registre el interceptor “cronometro” en el package demo.
Strust.xml
c. Añadió el interceptor “cronometro” al interceptor-stack pitStack.
Strust.xml
d. Pruebe la aplicación.
e. Aplique el mismo interceptor al ActionMapping “cargar”
Para ello, debe definir un nuevo interceptor-stack que incluya los

interceptores cronometro y paramsPrepareParamsStack
Luego, actualice la referencia en el ActionMapping.
f. Pruebe la aplicación.

1.1.7 Internacionalización – I18N
Tradicionalmente, los desarrolladores de software se centran en construir aplicaciones

que resuelvan en forma inmediata problemas de negocio. Mientras hacen eso es fácil
y a veces necesario realizar asunciones acerca del lenguaje o lugar de residencia de
los usuarios. En muchos casos, estas asunciones son válidas y no hay preguntas
sobre quién será la audiencia. Sin embargo, es probable, alguna vez, que se deba
reconstruir una aplicación, porque estas asunciones fueron incorrectas.
Internacionalización (I18N) es el proceso de diseñar un software con soporte

en tiempo real de múltiples lenguajes y regiones.
Dada esta característica, no será necesario rediseñar las aplicaciones cada vez que se
necesite soporte para un nuevo lenguaje. Una aplicación que dice tener soporte para
internacionalización debe contar con las siguientes características:
 Puede soportar lenguajes adicionales sin requerir cambios adicionales

de código.
 Los elementos de texto, mensajes e imágenes son almacenados
externamente al código fuente.
 Dependencia culturales de datos, tales como fecha y hora, y valores
decimales son correctamente formateados para el lenguaje del usuario
y localización geográfica.
 Caracteres no estándares son soportados.
 La aplicación puede ser fácilmente adaptada a nuevos lenguajes y
regiones.
Si un usuario visita un sitio web y todos sus textos, imágenes y botones están en el
lenguaje correcto, pero los números y fechas no son formateados correctamente, ésta
será una experiencia desagradable para el usuario.
Asegurar que una aplicación puede soportar múltiples lenguajes y regiones solo es el
primer paso. Se deben crear versiones localizadas de la aplicación para cada lenguaje
específico y región que debe soportar. Afortunadamente, aquí es donde los beneficios
de I18N en la plataforma java se ejecutan. Para aplicaciones que están siendo
apropiadamente internacionalizadas, todo el trabajo para soportar nuevos lenguajes o
naciones, son externas al código fuente.
Una Clase locale es una región (usualmente geográfica, pero no necesariamente) que
comparte personalizaciones, cultura y lenguaje. Aplicaciones que son escritas para
una sola localización son comúnmente referenciadas como miopes.
Localización (L10N) es el proceso de adaptar su aplicación, la cual ha sido

internacionalizada apropiadamente con la específica. Para aplicaciones donde el
soporte I18N no ha sido planeado o incorporado, esto usualmente significa cambios de
texto, imágenes y mensajes que son incluidos dentro del código fuente. Después de
los cambios aplicados, éste debe de ser recopilado. Imagine hacer eso cada vez para
una nueva localización soportada.
De acuerdo con Richard Gillam, miembro del Grupo de Tecnología Unicote (autor del
diseño de muchas de las librerías Java para soporte I18N), los usuarios esperarán que
los productos que utilizan trabajen para ellos en su lenguaje nativo. Se pueden obtener
experiencias negativas si los usuarios no están satisfechos cuando las asunciones que

se realizan son incorrectas. Se debe iniciar planificando, en forma temprana, el soporte

para I18N en las aplicaciones.
En Struts 2, el Soporte de i18N se logra a través del uso de lo siguiente:
 Archivos *.properties que contiene los textos.

 Interceptor
“com.opensymphony.xwork2.interceptor.I18nInterceptor”incluído en el
defaultStack
 En templates con el tag “text” para textos estáticos y en campos de
formulario con el atributo “key” para labels.
 En Actions, al utilizar el método “getText()” al momento de generar
ActionMessages, ErrorMessages y/o FieldErrors
En el caso de los archivos properties, su nombre debe seguir la nomenclatura:

“Nombre_idioma_pais.properties”, donde idioma se refiere a un código ISO 639-1 y
país a un código ISO 3166-1 (opcional).
Por ejemplo:
 textos.properties
 textos_en.properties
 textos_it.properties
 textos_en_US.properties
En el ejemplo, nótese que el primero no tiene códigos ISO en su nombre, lo cual indica
será el archivo principal a utilizar por defecto.
El archivo principal *.properties debe ser registrado en Strust.xml.
Por ejemplo, asumiendo que el archivo está en el paquete recursos.global:

LABORATORIO 7
Se va a configurar i18N en el proyecto base del curso.
Objetivo: Sistema debe soportar 2 o más idiomas
 La aplicación a importar es una plantilla base con funcionalidades

implementadas a la cual le añadirá soporte I18N.
Aplicación_07_inicio.war.
a. Prototipos:

b. Pasos a seguir:
2. Identifique tipos de textos utilizados en el proyecto.
3. Defina recursos de texto.
Un archivo properties se caracteriza por definir parámetros de configuración o textos

para I18N/L10N. Cada parámetro se almacena como un par de textos, donde el
primero es la clave para acceder al segundo (key=value).
Así, por ejemplo:
timeout=20
scope.default=request
registro.ok= Se realizó un registro en la tabla {0}
login.horaInicio= Usted accedió desde las #{session.login.horaInicio}

En la aplicación, cree el archivo texto.properties dentro de paquete “recursos” y

añada los textos identificados:
textos.properties

Se observan recursos con los textos en idioma español, identificados en el punto 2.

Dichos recursos tienen contenido estático y dinámico.
Los recursos dinámicos pueden definirse con parámetros {indice} (líneas 61,62,64 y
65) ó con OGNL (línea 60).
4. Registre el archivo textos.properties utilizando la constante

struts.custom.i18n.resources.
Strust.xml

5. Utilice los recursos de textos en la aplicación.
Cada vez que requiera utilizarse un recurso del properties, se le debe referenciar a
través de su key, por ejemplo:
En JSPs
 Login.jsp
En la línea 12, se definió texto estático con el tag text que apunta al property con
clave=”parrafo.login”.
En los campos de credenciales, se usó el atributo key (líneas 15 y 16).
En la línea 17, el label del botón se define con el método getText(‘key’).
 Principal.jsp
En esta página, se han definido todos los textos con el tag text.

En código Java
 UsuarioAction
Se observa el uso del método getText() de dos maneras:
En la línea 54, se envía únicamente el key para obtener texto estático

(“error.login.credenciales”) y en la línea 50 se envía además del key un arreglo de
Strings que contiene los parámetros requeridos por el texto dinámico
(“info.principal.fecha.acceso”).
Nota: Los key están encapsulados en constantes
7. Añada soporte de segundo idioma.
Para ello, cree, en el paquete recursos, el archivo: textos_en.properties, cuyo

contenido será el mismo que el del archivo textos.properties, solo que con valores
traducidos al Inglés.

textos_en.properties

8. Defina enlaces para que el usuario final pueda elegir idioma:

Login.jsp
Se requiere enviar a Struts el código ISO del idioma. Para ello se debe sobreescribir el
parámetro “request_locale”.
Strust.xml
Se define el ActionMapping para “idioma”.
Al utilizar como base el proyecto “Aplicacion_07_final.war”, se da soporte

de I18N con soporte de idioma español específico para Perú y Argentina.

1.1.8 Validaciones
Struts 2, también, brinda un Framework de Validación que permite validar los valores
de entrada de una página (típicamente de un formulario) antes de ejecutar un método
de procesamiento del Action.
Para ello, el Framework tiene definidas las interfaces Validateable y

ValidationAware.
a. Validateable:
• Contiene un único método void validate().
• El método puede ser sobreescrito en Clases Action para definir
validaciones.
b. ValidationAware:
• Verifica si hay errores asociados a la validación. De ser así detiene
la secuencia de ejecución y solicita retorno a la vista con Result con
name=input.
Ambas interfaces están implementadas en la Clase ActionSupport.
Las dos interfaces colaboran dentro del workflow de Struts2 si se ejecutan los
Interceptors “ValidationInterceptor” y “DefaultWorkflowInterceptor”.
En la configuración por defecto del Framework, tiene a ambos Interceptors

configurados en el defaultStack, según:
Validators
Son componentes de Validación que implementan la Interfaz

com.opensymphony.xwork2.validator.Validator .
El Framework proporciona Validators con reglas de validación comunes.
VALIDATORS
RequiredFieldValidator
RequiredStringValidator
IntRangeFieldValidator
LongRangeFieldValidator
ShortRangeFieldValidator
DoubleRangeFieldValidator
DateRangeFieldValidator
ExpressionValidator
FieldExpressionValidator

EmailValidator
URLValidator
VisitorFieldValidator
ConversionErrorFieldValidator
StringLengthFieldValidator
RegexFieldValidator
ConditionalVisitorFieldValidator
.
El Framework, también, permite implementar Validators personalizados que se ajusten
a la necesidad de la aplicación.
Configuración de Validaciones
Se sabe que, en las Clases Action, están declaradas las variables donde se
almacenan los valores de entrada. Si a dichas variables se quiere aplicar validaciones,
entonces el Action debe implementar ambas interfaces o heredar la Clase
ActionSupport.
Asimismo, en la configuración del ActionMapping, se debe añadir un Result con

name=”input”, el cual indica la página donde se mostrarán los errores de Validación.
Las técnicas de Validación son las siguientes:
• Programática
- Implementar método validate() en un Action, con toda la lógica de

validación a aplicar a uno o más campos.
- Se recomienda usar esta técnica solo cuando la lógica de validación es
muy compleja. De lo contrario, use la técnica declarativa.
Por ejemplo:
• Declarativa
- Se basa en el uso de Validators.

- Tiene dos alternativas para configurarlos:
• Anotaciones en Action a validar.
• Archivos XML creados en el mismo paquete donde se encuentra la

Clase Action a validar, que sigan la siguiente nomenclatura
• General para todos los métodos de un Action

NombreAction-validation.xml
• Específica para un ActionMapping
NombreAction-NombreActionMapping-validation.xml
Por ejemplo:
¿Cómo se ejecutan las validaciones durante un request?
• Una vez dentro de la ejecución del Interceptor-Stack, al llegar al

ValidationInterceptor, se invocan los métodos cuyo nombre empiecen con
validate() y las validaciones configuradas en XML o Anotaciones.
Dicho interceptor excluirá la ejecución de reglas a los métodos del Action

indicados en el parámetro “excludeMethods” en el Interceptor-Stack y/o
aquellos métodos del Action que tengan asignada la anotación
@SkipValidation
• Si se detecta uno o más errores de validación se generan ActionErrors o

FieldErrors según corresponda.
• Si la validación no detectó errores continúa la secuencia normal de
ejecución.
• En caso exista al menos un error de validación, el Framework retorna el
Result con name=“input”. Si no se definió dicho Result en el
ActionMapping asociado, el Framework genera un error durante la
ejecución.
REFERENCIA
http://struts.apache.org/release/2.3.x/docs/validation.html

LABORATORIO 8
Se va a configurar validaciones.
Objetivo: Validar campos de formulario del sistema

implementadas a la cual le añadirá validaciones de formulario.
Aplicación_08_inicio.war.
a. Prototipos:
b. Pasos a seguir:

2. Aplique validaciones en la página Login.
Caso: Todos los datos son requeridos

Solución: Tiene dos alternativas
a. Código Java
Debe sobreescribir el método validate del Action según lo siguiente:
UsuarioAction
En este método, puede realizar todas las validaciones necesarias a cada campos del
formulario. Por cada error encontrado, se añade un FieldError específico al
ValueStack, es por ello que cada fieldError se asocia a un campo en particular con el
respectivo mensaje de error.
Luego, configure, en el ActionMapping loginUsuario, el result con name=input.
Strust.xml
Pruebe la aplicación.

b. XML
En un archivo XML, se definirán los validators específicos por cada campo del
formulario.
Estos validators solo se deben aplicar al formulario de login, es decir cuando se

invoque al ActionMapping “loginUsuario” del action UsuarioAction. Es por ello que el
archivo xml se llamará:
UsuarioAction-loginUsuario-validation.xml
Cree el archivo xml en el mismo paquete del Action, según:
Luego, configure, en el ActionMapping loginUsuario, el result con name=input

(realizado en punto anterior).
Strust.xml

3. Añada soporte de I18N a los mensajes de validación.
Añada los textos a los archivos properties.
Referencie los recursos properties en los validators.
Observe el cambio en las líneas 9 y 14.
4. Añada validaciones en la página del registro de Empleado.
En un archivo XML, se definirán los validators específicos por cada campo del
formulario.

EmpleadoAction-registrarEmpleado-validation.xml
Observe en el campo empleado.nombre que se han configurado 2 validaciones las

cuales se ejecutarán en orden secuencial, sin considerar el resultado en cada una de
ellas.
Primero validará que el campo no tenga valor vacío, e inmediatamente después que
cumpla con la longitud máxima requerida.
Sin embargo, si se envía un valor vacío, el primer validator requiredstring detectará el

error, pero a pesar de ello, también, se ejecutará el siguiente validator stringlength,
aunque ya no tenga sentido.
Si quiere evitar procesamiento en vano de validaciones de un campo específico,

puede utilizar el atributo short-circuit con valor true, de modo que ante un error, en la
validación, se corte la secuencia de ejecución de las demás validaciones asociados a
dicho campo.
Luego, configure, en el ActionMapping registrarEmpleado, el result con name=input.

Strust.xml
Agregue los nuevos recursos de texto requeridos:
¿A qué se debe el error?
Dado que el formulario de registro de empleado tiene listas desplegables como

genero, es necesario que se ejecute el método prepare para que cargue los listados y
estén disponibles en caso se tenga que volver a mostrar dicho formulario por errores
de validación.
En un ejemplo anterior, se excluyó el método registrar del interceptor prepare, por lo

cual procederá a modificar según lo resaltado:
Strust.xml

5. Añada validaciones en los formularios del Mantenimiento de Vendedor.
VendedorAction-buscarVendedor-validation.xml
VendedorAction-editarVendedor-validation.xml
No olvide configurar el result con name=input en los ActionMapping según

corresponda:
Strust.xml

Asimismo, redefina el excludeMethods del prepare Interceptor quitando el método

editar:
Strust.xml
Pruebe nuevamente.
6. Ejercicio propuesto de investigación
En un nuevo proyecto, implemente páginas de ejemplo, donde se apliquen

los siguientes validators a campos de formulario:
VALIDATORS
IntRangeFieldValidator
DoubleRangeFieldValidator
DateRangeFieldValidator
ExpressionValidator
FieldExpressionValidator
EmailValidator
URLValidator
VisitorFieldValidator
ConversionErrorFieldValidator
RegexFieldValidator
ConditionalVisitorFieldValidator

1.1.9 Otros elementos de configuración
LABORATORIO 9
Se va a optimizar la configuración de la aplicación 8.
Objetivos: Conocer otros elementos/configuraciones de Strust.xml

implementadas.
a. Prototipos:
No se modificara la funcionalidad actual del sistema.
b. Pasos a seguir:
2. Reorganización de configuración en Strust.xml
Durante los laboratorios anteriores, ha implementado algunas pocas funcionalidades.

Sin embargo, el archivo de configuración de Strust.xml ha ido aumentado su
complejidad y, actualmente, lo tiene así:

Va a reorganizar los Action Mappings, agrupándolos por módulo en diferentes

packages, de modo que a futuro sea más fácil dar mantenimiento al sistema.
La configuración general para el proyecto se quedará en el package demo y la

específica para cada módulo en su respectivo package, los cuales heredarán la
configuración del package demo. Así, por ejemplo:

Strust.xml

Puede ordenar, un poco más, separando los packages en archivos de configuración

xml, por ejemplo:
El archivo principal seguirá siendo Struts.xml, el cual incluirá los demás archivos de
configuración haciendo uso del elemento include, según:
Strust.xml
Pruebe la aplicación para verificar que la funcionalidad no ha sido afectada.
3. Manejo de Excepciones y Global Results
El tratamiento de Excepciones lo pueden realizar los struts al recibir un Exception

desde cualquiera de sus componentes. Del lado de los Action, observe que todos los
métodos de procesamiento tienen definido un throws Exception, por ejemplo:
Lo que debe hacer, entonces, es configurar, de manera global o específica, lo que

quiere que realice dicho tratamiento.
 Global: Configuración aplicará para el package donde se declara y los

package que heredan el mismo.
 Específico: Configuración aplicará solo para el ActionMapping donde
se configure.

En el siguiente ejemplo, va a configurar, a nivel global, el manejo de dos tipos de

Excepción. Para ello, va a añadir las siguientes líneas de código en el package demo.
Strust.xml
Entre las líneas 41 y 49, se ha definido el tratamiento de 2 excepciones globales que

se aplicarán para todo el aplicativo. En caso de presentarse alguna de ellas, el
Framework redireccionará al result indicado evitando, de este modo, mostrar toda la
traza de excepción al usuario.
Los results mencionados son los configurados entre las líneas 36 y 39. Como se
observa, son results de tipo global, es decir que no pertenecen a ningun
ActionMapping. Dichas páginas las pueden encontrar en la carpeta paginas/error:
Va a verificar lo configurado simulando casos de error:
 NullPointerException
Ejecute el siguiente comando en mysql: drop database bd_daw1;
Pruebe la aplicación
 Cualquier otro Exception

Modifique temporalmente el SQL de método getUltimaFechaAcceso
para forzar error de tipo SQLException
UsuarioDAOMySql

Revierta los cambios de la simulación para dejar operativa nuevamente la aplicación.
4. Agrupación Lógica de Actions con namespaces
Va a ordenar, un poco más, la configuración de los ActionMappings asignando a cada

package un namespace que permita diferenciarlos unos de otros.
Struts-empleado.xml
Struts-seguridad.xml
Struts-vendedor.xml
Ahora, cada botón o enlace que invoque a alguno de los ActionMappings de los
paquetes con namespace personalizado deberá, también, indicar el namespace que
corresponda.
Por ejemplo:
Login.jsp
Se asigna namespace “/seguridad” en el tag form, por lo cual buscará el

ActionMapping “loginUsuario” en el package que tenga el mismo namespace, que en
este caso es:

Listado.jsp
Observe el uso del atributo namespace en el tag url.
Haga lo mismo en las demás páginas y vuelva a probar la aplicación.
Hay un error de configuración en el ActionMapping logoutUsuario, ya que invoca un

result que referencia a un Action que está en otro package, cuyo namespace es el
default. Vea de qué se trata en el siguiente gráfico:

Realice el cambio indicado y vuelva a probar la aplicación.

LABORATORIO 10
Se revisará el proyecto struts2-showcase.
a. Pasos a seguir:
1. Importar proyecto struts2-showcase.war
2. Identificar los componentes utilizados.
3. ¿Qué características adicionales encuentras?

1.1.10 Tiles
Al momento de crear el diseño de un sitio web típico, éste puede sufrir muchos
cambios durante su ciclo de vida. Utilizar diseños y gestores de diseño puede ayudar a
organizar las diferentes partes de un JSP de modo que éstos se puedan alterar con un
mínimo impacto para el resto de la aplicación.
Surge, de esta manera, el patrón de diseño Composite View, el cual permite, de

manera eficiente y escalable, gestionar diversos diseños para un sitio web.
Desafortunadamente, la tecnología JSP no proporciona ningún soporte directo para
diseños o gestores de diseño, es por ello que surgen librerías en el mercado que
pueden ser utilizadas para mejorar la estructura de las aplicaciones web.
Apache ha desarrollado un Framework de código abierto llamado Tiles que

implementa el patrón Composite View, el cual básicamente permite definir plantillas
para ser utilizadas en páginas de aplicación que comparten un diseño similar.
REFERENCIAS
https://tiles.apache.org/
https://tiles.apache.org/framework/tutorial/index.html

LABORATORIO 11
Se van a integrar Tiles con Struts 2.
Objetivos: Aplicar plantillas de diseño de página integrando Struts 2 con Tiles

implementadas.
a. Prototipos:

b. Pasos a seguir:

2. Revise las plantillas de diseño y sus secciones.
Plantilla.jsp
Cabecera.jsp

Menu.jsp
Pie.jsp
3. Añadir a WEB-INF/lib los jars de Tiles y el plugin de Tiles para Struts

4. Configure Tiles
a. Template
Plantilla donde se definen las secciones que mostrarán las páginas de la aplicación.
En el ejemplo, es la página Plantilla.jsp, la cual consta de 4 secciones: cabecera,
menú, contenido y pie de página.
Para poder hacer uso de los tags de Tiles, primero, debe referenciar su tag library:
Plantilla.jsp
En dicha página, utilizará el tag insertAttribute de Tiles para incluir contenidos

dinámicos en cada sección, según:
Plantilla.jsp
b. Definitions
Tiles trabaja en base a definitions, lo cual consiste en definir los contenidos que se
incluirán en las secciones del template.
Los definitions se crean en el archivo tiles.xml, el cual debe estar ubicado en la

carpeta WEB-INF.
Tiles.xml

Cree el definition base de la aplicación d_plantilla:
Tiles.xml
Observe que hace referencia al template Plantilla.jsp, por lo cual con el elemento put-
attribute se configura el contenido a incluir en cada una de las 4 secciones definidas
allí
5. Registre Listener de Tiles.
Web.xml
6. Ahora que Tiles está configurado, debe aplicarlo a las páginas que
requieran el diseño de la plantilla.
Según los prototipos, se tiene lo siguiente:
a. Login.jsp no requiere diseño de plantilla.

b. Principal.jsp si requiere diseño de plantilla, entonces:
b.1 Crear un definition
Cree un definition adicional que referencie a la página Principal.jsp.
Tiles.xml
Observe que el nuevo definiton hereda lo definido en d_plantilla, y únicamente

sobreescribe la sección “contenido” con la página Principal.jsp.
Nota importante:
Las páginas que serán utilizadas como secciones de un template deben tener
únicamente el código que corresponda justamente a dicha sección, por ejemplo:

Dado que Principal.jsp, ahora, representa una sección, es conveniente que solo
tenga el código que le corresponde, por tanto debería quedar así:
Principal.jsp
Nota: Los enlaces deben ser ubicados en la página Menu.jsp
Menu.jsp

b.2 Uso del definition
Dado que va a generar contenido de usuario final a partir de un definition de Tiles en el

contexto de Struts, significa que se trata de un nuevo ResultType, el cual viene
definido dentro del jar
Entonces, va a definir el ResultType de Tiles en el package demo.
Struts.xml
Ahora, debe aplicarlo en los ActionMapping que tengan results asociados a

Principal.jsp, según:
8. Ahora que ya sabe cómo configurar templates con Tiles, puede aplicar la
plantilla de diseño a las demás páginas del proyecto.
Al utilizar como base el proyecto “Aplicación_11_final.war”, puede definir un

template distinto a los módulos de Empleado y Vendedor.

1.2 PROYECTO PLANTILLA
1.2.1 Aplicación Web de 3 capas
LABORATORIO 12
Se ha venido trabajando sobre un proyecto base de 3 capas, en el cual la capa de

presentación ha evolucionado tras cada laboratorio.
Objetivos: Añadir soporte de FileUpload y muestra de Imágenes

implementadas.
a. Prototipos:

b. Pasos a seguir:
2. Upload de Imágenes: Registro de Vendedor
Añada, en el formulario de la página, el tag file, según:
Edicion.jsp
Observe que el formulario tiene un nuevo enctype, necesario para el envío de

archivos en el request.
En el Action, declare una variable global de tipo File con sus getter/setter.
VendedorAction
En este ejemplo, la imagen se guardará en base de datos, por ello en el método editar
se debe obtener el InputStream de la imagen para guardarlo en el campo foto del
bean Vendedor, el cual será enviado al servicio respectivo. Se añadió las líneas 68 a
70
VendedorAction

Pruebe la aplicación y verifique, en la base de datos, que la imagen haya sido

registrada correctamente.
3. Mostrar Imagen
Va a mostrar en la página Detalle.jsp la foto del vendedor.
En la capa de persistencia, ya se tiene la consulta SQL que obtiene los datos del
Vendedor incluyendo la foto (InputStream).
Aquí, tiene varias opciones para llevar la foto hasta la pantalla del usuario, por ejemplo
generar un File almacenándolo en un ruta del servidor para luego acceder desde el
JSP o enviar el InputStream directamente al Result. En el ejemplo, va a implementar la
segunda opción.
En el método detalle de VendedorAction, va a guardar temporalmente en Sesión dicho

InputStream. Esto debido a que, en un segundo request Struts, podrá acceder a dicho
objeto para mostrarlo en pantalla. El cambio está resaltado en la imagen.
VendedorAction
Ahora, va a crear un nuevo Action, según:

Este Action solo servirá para obtener el objeto InputStream de la sesión de modo que
lo exponga a un ResultType=stream.
Configure el respectivo ActionMapping en el package demo para que sea genérico:
Struts.xml
Observe que dada la casuística, el result es de tipo stream y está configurado para
obtener el objeto foto del Action.
Ahora, solo falta que la página donde se desea mostrar la foto invoque a este Action:
Detalle.jsp
Se ha añadido una fila en la tabla html para mostrar la foto.
4. Ejercicio propuesto de investigación
Al utilizar como base el proyecto “Aplicación_12_final.war”, implemente un

proyecto equivalente utilizando el Convention-Plugin de Struts y uso de
Anotaciones para la configuración de Action Mappings.

UNIDAD
2
FRAMEWORK DE PERSISTENCIA
MYBATIS
Al finalizar la unidad el alumno utilizando el Framework MyBatis implementa la
capa de persistencia de datos con Java.
TEMARIO
2.1 Tema 3 : Fundamentos
2.1.1. : Arquitectura y Configuración
2.1.2. : Mappers
2.1.3. : XML Mapped Statements
2.1.4. : Annotated Mapped Statements
2.1.5. : Otras configuraciones
2.2.1. : Aplicación Web

principales características del Framework MVC Struts 2 y el Framework
Mybatis.


2.1 FUNDAMENTOS
MyBatis es un Framework Open Source utilizado en aplicaciones orientadas a Objetos
para implementar la capa de Persistencia que opere con Bases de Datos Relacionales
MyBatis asocia objetos de modelo (JavaBeans) con sentencias SQL o procedimientos

almacenados mediante configuraciones en Interfaces con archivos XML y/o
anotaciones, simplificando las tareas del programador reduciendo la programación
directa con JDBC pues de ello se encarga el Framework. No se trata de un ORM.
Su uso se recomienda cuando se va a trabajar con Bases de Datos Relacionales

donde no se tiene injerencia y/o que son utilizadas por uno o más aplicativos. De lo
contrario, lo conveniente es utilizar un Framework ORM.
Versiones
 IBATIS 1.0 (2001) - Clinton Begin.
 IBATIS 2.0 (2004) - Apache Software Foundation
 MYBATIS 3 (2010) - Github
PÁGINA OFICIAL
http://mybatis.github.io/mybatis-3/
http://blog.mybatis.org/
RELEASES
http://blog.mybatis.org/p/products.html
API DOCUMENTATION
http://mybatis.github.io/mybatis-3/apidocs/reference/packages.html
SOURCE REFERENCE
http://mybatis.github.io/mybatis-3/xref/index.html

2.1.1 Arquitectura y Configuración
FUENTE DE IMAGEN
https://code.google.com/p/mybatis/

Componentes
 Mapped Statements
Un Mapped Statement se refiere a una sentencia SQL que ha sido configurada en

Mybatis con XML y/o Anotaciones.
Vea un ejemplo de sentencia SQL: Select
a. XML
b. Anotaciones
 Mapper
Son interfaces que se enlazan con los Mapped Statements definiendo un método por
cada sentencia SQL.
Por ejemplo: XML Mapped Statement
Para obtener una instancia del Mapper se utiliza la interfaz SqlSession y debe
realizarse dentro de un método.

 SqlSessionFactory
Una aplicación que usa MyBatis debe utilizar una instancia de SqlSessionFactory que
utilizará una única base de datos. Dicha instancia se obtiene a partir de un archivo de
configuración XML.
Se debe crear como un Singleton en el contexto de la aplicación, de modo que su

instancia exista mientras la aplicación esté corriendo en el servidor y esta no debe ser
recreada o eliminada.
Por ejemplo, revise la siguiente Clase utilitaria para crear el SqlSessionFactory:
Según la imagen, en el bloque estático de la Clase utilitaria, primero, se carga en

memoria el archivo XML que contiene la configuración de Mybatis, luego construye la
instancia del SqlSessionFactory utilizando el método build de la Clase
SqlSessionFactoryBuilder.
Una vez cargado en el contexto de la aplicación el SqlSessionFactory proveerá de

instancias de SqlSession.

 SqlSession
Es una interfaz Java que permite manejar transacciones, obtener Mappers y ejecutar
Mapped Statements.
Para poder utilizarlo se requiere que esté declarado en un método, así por ejemplo:
En la línea 18, se obtiene instancia del SqlSession utilizando uno de los métodos de
la interfaz SqlSessionFactory.
Una vez abierto el SqlSession, en la línea 20, se procede a obtener el Mapper.

Luego, en las líneas 21 y 22, se ejecutan los MappedStatements con el commit
respectivo y, finalmente, se cierra el SqlSession.
La creación del SqlSession se debe dar por cada request a procesar, ya que no es
Thread Safe y no debe ser compartida, es por ello que por cada hilo de ejecución se
debe tener una única instancia.

LABORATORIO 13
Se implementará, desde cero, la primera aplicación con MyBatis en un proyecto

Standalone.
Objetivos: Implementar una operación de consulta SQL con MyBatis
 Solo se implementará la capa de negocio y persistencia.

 Descargue de moodle el archivo recursos.zip y descomprimirlo.
a. Script:
drop database if exists bd_mybatis;
create database bd_mybatis;
use bd_mybatis;
create table tb_cliente(

cod_cli smallint not null auto_increment,
nom_cli varchar(30),
ape_cli varchar(30),
eda_cli smallint,
dir_cli varchar(30),
PRIMARY KEY (cod_cli)
);
insert into tb_cliente

values(null,'Jorge','Arcos',25,'Avenida');
values(null,'Maria','Guitarra',28,'Calle');
b. Pasos a seguir:
1. Cree Java Project con nombre Aplicación_13.
Ir a opción

Dé clic en Next.

Referencie la librería jar de Mybatis y el driver de conexión a MySql.
Nota: Ubicación de jars
Finalmente, dé clic en Finish.

2. En el paquete model, cree el bean asociado a la tabla tb_cliente.
No olvide generar los métodos getter/setter y sobreescribir el método toString.
3. Configuración MyBatis en el proyecto
a. Cree el archivo de configuración principal de Mybatis mybatis-

config.xml en el paquete mybatis.config
Mybatis-config.xml
<!DOCTYPE configuration
PUBLIC "-//mybatis.org//DTD Config 3.0//EN"
"http://mybatis.org/dtd/mybatis-3-config.dtd">
<configuration>
</configuration>
b. Defina el Environment.
Mybatis-config.xml

c. Utilitario para obtener SqlSessionFactory
Cree la Clase MyBatisUtil en el paquete mybatis.
4. Consulta SQL que obtiene todos los clientes.
5. Implementación de consulta SQL en MyBatis
a. En el paquete mybatis.mapper, cree el archivo ClienteMapper.xml

que contendrá el XML Mapped Statement, según:
ClienteMapper.xml
<!DOCTYPE mapper
PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
"http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="">
</mapper>

b. Configure un mapped statement con la consulta SQL
ClienteMapper.xml
c. En el paquete mybatis.mapper, cree la interfaz ClienteMapper.java

que actuará como Mapper.
ClienteMapper.java
d. Ahora, debe asociar el XML con la interfaz.

Para ello, haga uso del atributo namespace, según:
ClienteMapper.xml

6. Ejecute la consulta SQL.
En el paquete service, cree la Clase TestService cuya implementación es la

siguiente:
En el método ejemplo, se implementa el consumo del Mapper:
 Linea 35: Se obtiene SqlSessionFactory para abrir sesion de

MyBatis
 Linea 37: Se obtiene el Mapper requerido
 Linea 38: Se ejecutá un método del Mapper.
 Línea 40: Se cierra la sesión de MyBatis.
El método main simula ser un cliente que solicita la ejecución de la funcionalidad del
caso, cuyo resultado se muestra en consola:
Consola

Configuración
 mybatis-config.xml
Es el archivo maestro de configuración del Framework que servirá para personalizar el

funcionamiento del mismo, así como definir conexiones a base de datos, mappers,
alias, etc.
Ejemplo básico de configuración:
Se pueden configurar los siguientes elementos:
REFERENCIAS
http://mybatis.github.io/mybatis-3/es/configuration.html

Se va a detallar los elementos principales:
a. properties
Contiene propiedades externalizables y sustituibles que se pueden

configurar en un archivo *.properties o directamente mediante
subelementos <property>.
Por ejemplo:
b. settings
Permite al programador redefinir el comportamiento por defecto de MyBatis, por

ejemplo la propiedad defaultStatementTimeout establece el número de segundos
que debe esperar el driver la respuesta de la base de datos.
Por ejemplo:

c. environments
Permite definir un entorno de trabajo por cada base de datos que utilizará la
aplicación. Cada entorno define el Gestor de Transacciones y un DataSource para
conectarse a Base de Datos.
El SqlSessionFactory es el objeto que referencia a un environment en tiempo de

ejecución.
En una aplicación, puede definir uno o más environments según el número de base de
datos con los que trabajará. Por ejemplo, si tiene dos environments, al generar el
SqlSessionFactory, se debe indicar el id del Environment que referenciará.

En cada Environment, se puede configurar lo siguiente:
 transactionManager
El gestor de la transacción puede ser de dos tipos:
- JDBC: Uso de Commit y Rollback de JDBC en la programación. La

interfaz SqlSession provee de un método para cada caso.
- MANAGED: Contenedor es responsable del ciclo de vida de una
transacción.
No es requerido si aplicación utiliza SPRING Framework.
 dataSource
Define la configuración de conexión a Base de Datos.
Se puede realizar de 3 maneras:
- UNPOOLED: Abre y cierra conexión por cada petición.

- POOLED: Define un Connection Pooling gestionado por la
aplicación.
- JNDI: Utiliza un Connection Pooling gestionado por un Contenedor.
d. mappers
Elemento utilizado para indicar la ruta completa de cada uno de los mappers a utilizar
en la aplicación o para indicar cuál es el paquete donde se encuentran todos los
mappers.
Por ejemplo:
e. typeAliases
Sirve para definir un alias a objetos, normalmente del modelo. Se puede asociar un
alias a cada objeto individualmente o indicar el paquete donde se encuentran dichos
objetos.

LABORATORIO 14
Se implementará una versión mejorada de aplicación con mybatis.
Objetivos: Optimizar la configuración base del proyecto anterior
 La aplicación a importar es una plantilla base con capa de negocio y

persistencia implementadas.
 No se modificará la funcionalidad existente. Solo se implementará.
a. Script:

use bd_mybatis;

eda_cli smallint,
);


b. Pasos a seguir:
1. Importe como proyecto de workspace la Aplicación_14_inicio.

Referencie la librería jar de Mybatis y el driver de conexión a MySql (Ver procedimiento

en laboratorio 13).
2. Amplie la configuración base de mybatis.
Mybatis-config.xml
Cambios:
 Elemento settings: Ha definido 2 segundos como tiempo máximo de

espera de ejecución de una sentencia SQL. Pasado ese tiempo,
mybatis lanzará una excepción de timeout.

 Elemento properties: Ha definido en un archivo externo parámetros de

configuración, léase datos de conexión a base de datos:
 Elemento typeAlias: Ha definido alias a cada objeto del Modelo, de

modo que no tenga que tipear la ruta completa del objeto cada vez que
sea utilizado en los XML Mapped Statements.
 Elemento package del mapper: Permite definir el paquete donde se

encuentran todos los mappers del proyecto evitando, de esta manera,
estar declarando uno por uno cada mapper.

MyBatisUtil
Se ha definido específicamente el environment que se utilizará para generar el

SqlSessionFactory.

2.1.2 Mappers
Los Mappers son interfaces que se enlazan con los Mapped Statements definiendo
un método por cada sentencia SQL. No requiere extender o implementar ninguna
Clase y permiten reducir en casi 100% el uso de JDBC en la programación.
 Mapper con XML Mapped Statements
Si tiene definidos Mapped Statements en un archivo XML, en una interfaz Java, se

debe definir el mismo número de métodos, cuyo nombre sea igual al id respetando los
argumentos y tipo de retorno asociado a cada operación.
El uso del atributo namespace permite asociar el archivo XML con la interfaz
indicando la ruta completa de paquetes y nombre de Interfaz, tal como se observa en
la imagen. Considere que el uso de namespace es obligatorio en Mybatis.
En una aplicación típica, se debe definir un Mapper por cada archivo XML de Mapped
Statements.

 Mapper con Annotated Mapped Statements
Como alternativa al uso de archivos XML, los Mapped Statements también pueden
definirse con Anotaciones directamente en cada método del Mapper, por ejemplo:
En una aplicación típica, se definen tantos Mappers como tablas existan en la base de
datos permitiendo agrupar por afinidad los Mapped Statements.
El uso de XML ó Anotaciones para Mapped Statements no implica mayor

diferencia y su elección depende del programador.

2.1.3 XML Mapped Statements
Son archivos para realizar mapeo de sentencias SQL.
Típicamente se crea un archivo XML por cada tabla existente en la base de datos, con
el objetivo de agrupar por afinidad los Mapped Statements.
Contenido base
Elementos
REFERENCIAS
http://mybatis.github.io/mybatis-3/es/sqlmap-xml.html
Se va a conocer los elementos y atributos básicos.
a. Para definir sentencias SQL del CRUD, tiene los elementos insert, select,
update y delete respectivamente.
En cada uno de ellos, se puede definir el comportamiento con los siguientes atributos:
- Atributo id para asignarle un identificador.

- Atributo parameterType especifica el tipo de objeto que contiene uno o
más parámetros.
- Atributo parameterMap está deprecado.
- Atributo statementType para especificar si SQL se debe tratar como
STATEMENT, PREPARED ó CALLABLE. Por defecto es PREPARED.
- Atributo timeout establece el número de segundos que el driver
esperará a que la base de datos responda antes de lanzar una
excepción.

- En el body del elemento, se escribirá la sentencia SQL. Los parámetros

requeridos por dichas sentencias deben tener esta sintaxis:
#{parametro} cuyo valor dependerá del parameterType asignado.
En el caso del elemento insert, se tienen estos atributos adicionales:
- Atributo useGeneratedKeys cuando está activo (true) obtiene el valor

de la llave autogenerada luego de ejecutar el insert.
- Atributo keyProperty para indicar la propiedad donde se guardará el
valor de la llave obtenida luego del insert. Depende del atributo
useGeneratedKeys.
- Atributo keyColumn para indicar nombre de la columna definida como
llave primaria. Su uso depende del motor de base de datos. No es
necesario en MySql.
En el caso del elemento select, se tienen estos atributos adicionales:
- Atributo resultType específica el tipo de objeto que se utilizará para

mapear el resultado de la consulta SQL. Usualmente un objeto del
modelo.
- Atributo resultMap hace referencia al objeto definido con el elemento
del mismo nombre.
- Atributo resultSetType para especificar el tipo de recorrido en el
ResultSet. Valores posibles FORWARD_ONLY, SCROLL_SENSITIVE,
SCROLL_INSENSITIVE.

b. El elemento sql sirve para definir porciones de código sql reutilizables que
se pueden incluir dentro de las sentencias SQL con el subelemento
<include>
c. El elemento resultMap describe la estructura del Objeto que almacenará

los resultados de una o más consultas SQL. Para ello mapea una por una
todas las columnas, que retornará la consulta, con objetos Java, indicando
el tipo de dato JDBC como Java respectivamente.
d. El elemento parameterMap está deprecado.

IMPORTANTE
Por cada Mapped Statement, se debe definir, en la interfaz asociada según el

namespace, un método cuyo nombre sea igual a su id respetando los parámetros y
tipo de retorno.
Por ejemplo:

LABORATORIO 15
Se implementarán operaciones CRUD con XML MappedStatements.
Objetivos: Comprender el uso de XML para configurar operaciones CRUD en

MyBatis.
 La aplicación a importar es una plantilla base con capa de negocio y

persistencia implementadas. Viene con la configuración base realizada
en laboratorio anterior.
a. Script:

use bd_mybatis;

eda_cli smallint,
);


b. Pasos a seguir:


en laboratorio 13).
2. Definición de operaciones CRUD en XML Mapped Statements
ClienteMapper.xml
 Liste todos los clientes.
 Registre un cliente.
 Elimine un cliente.
 Modifique datos de un cliente.
En los tres últimos XML Mapped Statement, se define un parámetro de entrada de tipo
Cliente (registrar y modificar) o de tipo Integer (eliminar).
En el caso del tipo Cliente, el Mapped Statement recibe un bean que encapsula los
datos del cliente, los cuales son accedidos directamente en los SQL utilizando la

expresión #{atributo del bean}. En el caso del tipo simple, se utiliza la misma
expresión #{alias} cuyo contenido puede ser cualquier texto ya que es un único dato
de entrada.
 Liste datos básicos de todos los clientes.
Dado que la sentencia SQL no devuelve todos los datos del cliente, es recomendable
definir ello en un elemento resultMap, de modo que se especifíque cuales seran los
campos del type a poblar.
Adicional a ello, con el elemento id, indique cuál es el campos a indexar para optimizar
el rendimiento al recorrer el List.
Una vez definido el resultMap, se procede a referenciarlo desde el XML Mapped

Statement que lo requiera (en este caso getClientesBasico).
Nota: Ya no es necesario que columnas de la consulta SQL tengan definido un alias.
 Obtenga datos básicos de un solo cliente.
Esta consulta SQL devuelve exactamente los mismo datos de la consulta anterior, con
la diferencia que tiene un filtro de llave primaria. Por ende, puede reutilizar el
ResultMap rmClienteBasico.
3. Defina operaciones en Interfaz ClienteMapper.
Declare los métodos de acuerdo a los XML Mapped Statements definidos:

ClienteMapper
4. Consuma métodos de la Interfaz.
En la Clase TestService, debe implementar los métodos declarados considerando el

tipo de retorno y argumentos a enviar.
TestService

 Modifique los datos de un cliente.
 Liste datos básicos de todos los clientes.
5. Pruebe la aplicación en modo depuración y observe el resultado de la

ejecución método por método.

6. Consulta SQL que retorna datos calculados
 Consulta SQL
 ClienteMapper.xml
Aplique el mismo principio del uso de ResultMap. En este caso, las columnas de la
consulta son campos calculados que no pertenecen a ningun bean. Una opción válida
es almacenar los valores en un Map, lo cual ha definido en el ResultMap
rmClienteReporte.
En este caso, es necesario definir el javaType para una conversión correcta del
JDBCType de la columna al atributo Java que le corresponda.
 ClienteMapper
 TestService

ejecución del método.

2.1.4 Annotated Mapped Statements
La gran mayoría de configuraciones a realizar en XML Mapped Statements, también

lo puede realizar con anotaciones directamente en cada método del Mapper.
Dentro de las anotaciones para definir sentencias SQL, tiene lo siguiente:
@Insert
@Update
@Delete
@Select
En cada una de ellas, debe definir el SQL que corresponda.
Por ejemplo:
Asimismo, si se requieren parámetros, se debe utilizar la anotación @Param, por

ejemplo:
En caso los parámetros lleguen encapsulados en un objeto del modelo, no es

necesario el uso de @Param, por ejemplo:
En caso de las consultas que requieran ResultMap, se tienen dos alternativas
a. Defina Result Map con Anotaciones.

b. Referencie a ResultMap definido en archivo XML.
El uso de una u otra alternativa dependerá de la complejidad en la

configuración.
REFERENCIAS
http://mybatis.github.io/mybatis-3/java-api.html (Sección Mapper Annotations)

LABORATORIO 16
Se implementará una versión similar a la aplicación del laboratorio 15 con mybatis con
el uso de Annotations.
Objetivos: Comprender el uso de Annotations para configurar operaciones CRUD en

MyBatis.
 La aplicación a importar es idéntica a la aplicación_15_final.

 Va a migrar el uso de XML Mapped Statements a Annotation Mapped
Statements.
a. Script:

use bd_mybatis;

eda_cli smallint,
);


b. Pasos a seguir:


en laboratorio 13).
2. Defina operaciones CRUD en el Mapper con Annotated Mapped

Statements.
Nota: Las operaciones SQL son las mismas que vio en el laboratorio 15.
ClienteMapper.java
 Modifique datos de un cliente.
En los tres últimos Annotated Mapped Statement, se define un parámetro de entrada

de tipo Cliente (registrar y modificar Edad) o de tipo Integer (eliminar).
En el caso del tipo Cliente, el Mapped Statement recibe un bean que encapsula los
datos del cliente, los cuales son accedidos directamente en los SQL utilizando la
expresión #{atributo del bean}.
En el caso del tipo simple, cada parámetro tendrá asociado la anotación @Param que
sirve para asignar un alias al parámetro, el cual se utilizará en el SQL con la expresión
#{alias}. Esta anotación es opcional en caso solo haya un argumento en el método.

 Liste los datos básicos de todos los clientes.
Dado que la sentencia SQL no devuelve todos los datos del cliente, es recomendable
definir ello en un elemento @Results, de modo que se especifíque cuales seran los
campos del Bean a poblar.
Adicional a ello, con el atributo id=true, indique cuál es el campo a indexar para
optimizar el rendimiento al recorrer el List.
Nota: Ya no es necesario que columnas de la consulta SQL tengan definido un alias.
Esta consulta SQL devuelve exactamente los mismo datos de la consulta anterior, con
la diferencia que tiene un filtro de llave primaria. Sin embargo, no puede reutilizarlo.
Por ello, debe definir nuevamente un @Results con los campos del Bean a poblar.
 Consulta SQL que retorna datos calculados
En este caso, es necesario definir el javaType para una conversión correcta del
JDBCType de la columna al atributo Java que le corresponda.
3. La interfaz ClienteMapper y el TestService no se verán afectados por los

cambios.

ejecución del método.

2.1.5 Otras configuraciones
LABORATORIO 17
Objetivos: Conocer otras características importantes de MyBatis

implementadas.
Aplicación_17_inicio.
a. Script:

use bd_mybatis;

eda_cli smallint,
);

values(null,'Mariella','Gomez',29,null);

use bd_mybatis;
DELIMITER $$
DROP PROCEDURE IF EXISTS sp_nuevoCliente_1 $$
CREATE PROCEDURE sp_nuevoCliente_1 (
IN nombre VARCHAR(30),
IN apellido VARCHAR(30),
IN edad INT,
IN direccion VARCHAR(30),
OUT codigo INT)
BEGIN
insert into tb_cliente(NOM_CLI, APE_CLI, EDA_CLI,DIR_CLI)

values(nombre, apellido,edad,direccion);
select last_insert_id() into codigo;
END $$
DELIMITER;
DELIMITER $$
DROP PROCEDURE IF EXISTS sp_nuevoCliente_2 $$
CREATE PROCEDURE sp_nuevoCliente_2 (
IN nombre VARCHAR(30),
IN apellido VARCHAR(30),
IN edad INT,
IN direccion VARCHAR(30),
OUT codigo INT,
OUT mensaje VARCHAR(40))
BEGIN
insert into tb_cliente(NOM_CLI, APE_CLI, EDA_CLI,DIR_CLI)

values(nombre, apellido,edad,direccion);
select last_insert_id() into codigo;
if(edad > 50) then

SET mensaje='USTED TIENE TARIFA PREFERENCIAL';
else
SET mensaje='USTED TIENE TARIFA REGULAR';
end if;
END $$
DELIMITER;
DELIMITER $$
DROP PROCEDURE IF EXISTS sp_buscarCliente $$
CREATE PROCEDURE sp_buscarCliente (IN filtro VARCHAR(30))
BEGIN
SELECT cod_cli,
nom_cli,
ape_cli
FROM tb_cliente
WHERE nom_cli=filtro;
END $$

b. Pasos a seguir:

Referencie a la librería jar de Mybatis y el driver de conexión a MySql (Ver

procedimiento en laboratorio 13).
2. Uso de Stored Procedures
Para invocar a un procedure, debe tener en cuenta dos aspectos importantes:
a. Uso de sintaxis {CALL nombreSP(#{parámetro1},#{parámetro2}) }

b. Statement es de tipo CALLABLE
Después de ello, el tratamiento en Mybatis es similar al que ha visto en anteriores

laboratorios.
Ejecute el script del archivo procedures.
Vea los siguientes ejemplos que consumen los Stored Procedure creados:
 Se obtiene un ResultSet (Cursor) desde un Stored Procedure.
ClienteMapper.xml
ClienteMapper.java

TestService.java
 Envíe datos de cliente a un Stored Procedure para realizar el registro en

la tabla cliente. Como resultado, se obtiene el código autogenerado.
ClienteMapper.xml
ClienteMapper.java
El Stored Procedure sp_nuevoCliente_1 además de recibir parámetros del bean

cliente, retorna un campo entero con el código autogenerado del cliente, por lo cual
adicionalmente se ha definido el parámetro id con mode=OUT indicandole el
jdbcType respectivo.
TestService.java

 Envíe datos de cliente a un Stored Procedure para realizar el registro en

la tabla cliente. Como resultado, se obtiene un mensaje informativo de
acuerdo a la edad ingresada.
ClienteMapper.xml
ClienteMapper.java
Este caso es similar al anterior, salvo por los campos de retorno del stored procedure
sp_nuevoCliente_2, pues además del código autogenerado devuelve un mensaje
informativo. Este último campo no pertenece al bean cliente ni a ningun otro bean
asociado, por lo cual es necesario utilizar un Map que contenga tanto el bean del
cliente como un objeto String para el mensaje.
TestService.java
Pruebe la aplicación en modo depuración y observe el resultado de la ejecución de

ambas consultas.

3. Dynamic SQL
Se va a ver ejemplos básicos del uso de elementos que permiten manipular el SQL
definido:
 IF
En este ejemplo, se está controlando que la clausula WHERE solo se aplique en caso
el usuario final desee filtrar por edad el cálculo del total. Si no envía edad, entonces el
WHERE no formará parte de la consulta SQL a ejecutar.
ClienteMapper.xml
ClienteMapper.java
TestService.java

 FOREACH
En este ejemplo, el cliente tendrá la opción de enviar una o más edades de clientes a
considerar en el cálculo del query.
El elemento foreach permite recorrer el conjunto de parámetros, en este caso las

edades, e ir concatenándolos para formar el contenido requerido. En este caso, se
definen los datos a setear en la cláusula IN de la consulta SQL.
ClienteMapper.xml
ClienteMapper.java
TestService.java

 WHERE / CHOOSE
En este ejemplo, se requiere ejecutar un único filtro a la consulta SQL según el dato
ingresado por el cliente, que puede ser apellido o nombre. Si cliente no envía filtro,
por defecto se filtrarán los registros de clientes cuya dirección sea diferente a NULL.
El elemento choose permite configurar lo indicado, similar a lo que en Java se realiza

con un switch/case.
El elemento where permite controlar la aparición de la cláusula del mismo nombre

según el contenido resultado de la evaluación de los elementos internos. En caso el
contenido empiece con AND o OR, lo quita para evitar error de sintaxis.
ClienteMapper.xml
ClienteMapper.java
TestService.java
REFERENCIA
http://mybatis.github.io/mybatis-3/dynamic-sql.html

2.2.1 Aplicación Web
LABORATORIO 18
Se implementará una nueva versión del proyecto base.
Objetivos: Migrar capa de negocio y persistencia del proyecto base aplicando

MyBatis.
 La aplicación a importar es la plantilla base con funcionalidades

implementadas utilizando Struts 2 – Servicios – JDBC.
 Script de Base de datos y componentes base serán entregados junto
con proyecto Aplicación_18_inicio.war.
 Se ha modificado el tipo de Objeto del atributo foto (de InputStream a
byte[]) en el bean Vendedor, por compatibilidad con el Framework
MyBatis.
a. Prototipos:

b. Pasos a seguir:
Proyecto no tiene capa de persistencia ni servicios implementados.
2. Se va a crear y configurar Mybatis con lo mínimo necesario.
 Añada el jar de MyBatis a la carpeta WebContent/WEB-INF/lib.
 Copie la Clase utilitaria MyBatisUtil.java al paquete útil (lo encontrará

en carpeta componentes de laboratorio 18.zip)

 Cree los paquetes:
 Añada, al paquete persistencia.mybatis.config, el archivo mybatis-

config.xml y config.properties (los encontrará en carpeta
componentes de laboratorio 18.zip)
 En el paquete persistencia.mybatis.mapper, cree tantas Interfaces y

XML como tablas tenga la base de datos.
3. Ahora, va a implementar los mappers considerando las misma sentencias

SQL utilizadas en Aplicación_12_final.
CargoMapper

CargoMapper.xml
DistritoMapper
DistritoMapper.xml
UsuarioMapper

UsuarioMapper.xml
EmpleadoMapper
EmpleadoMapper.xml
VendedorMapper

Nota: Observe el contenido del elemento insert. Allí encontrará lo siguiente

#{distrito.codigo}. ¿A qué se refiere este código?
Como vio, en su momento, las Clases del modelo están relacionadas entre sí, por
ejemplo, en el proyecto, la Clase Vendedor tiene relación unidireccional con la Clase
Distrito y Empleado con la Clase Cargo.
Entonces, a partir de una instancia de Vendedor, se puede acceder a los atributos de

distrito. Es, por ello, que, en el insert, primero se accede al distrito del Vendedor y, de
allí, se obtiene el código. A esto último se denomina acceso por anidamiento de
objetos, lo cual es una técnica genérica y lo ha usado, muchas veces, en los
laboratorios anteriores.
VendedorMapper.xml
Nota: Observe la línea 22. Allí se ha utilizado el elemento association.
¿Para qué sirve ese elemento?
Como se comentó anteriormente, en el modelo, tiene Clases relacionadas. Entonces,

cuando se tienen consultas SQL que retornan datos de una tabla, así como de sus
tablas relacionadas, por ejemplo con un JOIN, debe definir un ResultMap que
contemple dicho escenario.
En el ResultMap rmVendedorByPK, se definen los campos propios de dicha Clase

con el elemento result, pero los campos que representan relaciones, en este caso el

bean Distrito con el elemento association. En él, se asocia el atributo del bean
Vendedor(distrito) con el tipo de Objeto (alias distrito); y, al interno, cada uno de los
campos requeridos por la consulta SQL, con el elemento result.
4. Es necesario declarar los TypeAliases de los objetos del modelo que ha

utilizado.
Mybatis-config.xml

5. Ya ha terminado de implementar la capa de persistencia. Ahora, va a

consumirla desde los servicios de negocio:
CargoServiceDAO
DistritoServiceDAO
LoginServiceDAO

VendedorServiceDAO

EmpleadoServiceDAO
7. Ejercicio complementario
 Importar proyecto Aplicación_18_intermedio.war
 Connection Pooling con JDNI
Hay que definir en TOMCAT un recurso de tipo DataSource.
Cree el archivo context.xml en la carpeta WebContent/META-INF y

añada lo siguiente:
context.xml

Luego, redefina, en mybatis-config.xml, el datasource según lo

siguiente:
Mybatis-config.xml

UNIDAD
3
REPORTES CON JASPER
Al término de la unidad el alumno utilizando el Framework STRUTS 2 Jasper
Reports y la herramienta IReport implementan una aplicación web que genera
reportes gráficos con criterios de búsqueda dinámicos y acceso a base de
datos con MyBatis.
TEMARIO
3.1 Tema 5 : Jasper Reports
3.1.1. : Diseño e implementación de reportes con la
herramienta IReport Designer
3.2.1. : Integración de Struts 2 y JasperReport

principales características del Framework MVC Struts 2 y jasperReport.


3.1 JASPER REPORTS

Jasper Reports es un lenguaje para generación de reportes en Java, trabaja en forma
similar a un compilador y a un intérprete.
El programador diseña el reporte codificándolo en XML de acuerdo con las etiquetas y

atributos definidos en un archivo llamado jasperreports.dtd. Durante el diseño, se
define completamente el reporte describiendo dónde colocar texto, imágenes, líneas,
rectángulos, origen de los datos, ciertos cálculos como promedios, totales, etc.
Este archivo fuente XML debe ser compilado para obtener un reporte real. La versión
compilada de fuente es nombrada con extensión “jasper".
Para ejecutar reportes en Java, se necesita considerar la aplicación del archivo

compilado (.jasper) que recibirá los datos a visualizar de la aplicación. Dichos datos
pueden ser recuperados desde varias fuentes como Bases de Datos, JavaBeans,
archivos XML, etc.
Para facilitar el trabajo del programador, existe una herramienta llamada iReport, la
cual es un constructor y/o diseñador de reportes visual, fácil de usar para generar
reportes con Jasper. Esta herramienta permite también que los programadores corrijan
visualmente reportes complejos como cartas, imágenes, subreportes, etc.
Para un reporte el archivo generado por la herramienta iReport es de tipo “jrxml”, en

el cual se encontrará el diseño y estilo del reporte, el cual al compilarse genera el
archivo de tipo “jasper”.
iReport también está integrado con la biblioteca gráfica “JFreeChart”, una de las más
difundidas para Java. A continuación, se enumeran las principales características de
esta herramienta:
 100% escrito en JAVA y, además, de uso libre y gratuito

 Manejo de las etiquetas de JasperReports
 Permite diseñar con sus propias herramientas: rectángulos, líneas,
elipses, campos de los textfields, cartas, subreportes.
 Soporta internacionalización.
 Recopila y exporta integrados
 Soporta JDBC
 Soporta JavaBeans como orígenes de datos
 Incluye asistentes para crear automáticamente informes.

3.1.1 Diseño e implementación de reportes con la herramienta IReport

Designer
LABORATORIO 19
Se implementará el primer reporte.
Objetivos: Aplicar plantillas de diseño de página integrando Struts 2 con Tiles
 Script de Base de datos e imágenes se encuentra en carpeta

laboratorio_19_inicio.
a. Prototipos:
b. Pasos a seguir:
1. Descargar aplicación Ireport-Designer
 Ir a Enlace:
http://sourceforge.net/projects/ireport/files/iReport/iReport-5.5.0/
 Seleccione el archivo *.zip
 Descomprimir archivo en C:\
 Ejecute el archivo C:\iReport-5.5.0\bin\ireport.exe

2. Definir DataSource
 Dé clic en ícono.
 Seleccione New.

 Seleccione Database JDBC Connection y dé clic en Next.
 Ingrese datos de Conexión a la base de datos.

 Dé clic en Test.
 Finalmente, dé clic en Save.
 Cree el reporte seleccionando el menú Archivo / New.
 Seleccione Blank A4 y dé clic en Open this Template.

 Ingrese el nombre de reporte “reporte_simple_1” dentro de la carpeta

laboratorio 19, dé clic en Siguiente y, luego, en Terminar.

 Se muestra el reporte creado
 En la sección Title, añada “Static Text” (label) arrastrando de la Paleta.
 Modifique el texto según prototipo.

 Compile y Previsualice . Observe que no se muestra ninguna

página. Esto porque, áun, no ha configurado data dinámica.
Nota: Al compilar correctamente el archivo *.jrxml, se debe haber generado un archivo

*.jasper, el cual será el que, finalmente, utilice en las aplicaciones.
Para poder previsualizar el diseño, puede variar la configuración default, por ejemplo,
ir a propiedades del reporte y cambiar el valor del siguiente atributo:

 Previsualice nuevamente.
 Para obtener datos de vendedores, va a definir una consulta SQL.

La herramienta autogenerá un field por cada columna mapeando el tipo de dato con
su equivalente en Java. Asimismo, podrá previsualizar la data a recibir.
 De clic en OK y observe la generación de Fields en el Report

Inspector.
 Seleccione y arrastre los 3 Fields a la sección Detail del reporte.
Los Fields se caracterizan por contener valores dinámicos. Su nomenclatura consiste

en $F{NOMBRE}

 Compile y Previsualice
 Observe que filas están muy separadas, entonces ajuste la altura de las
secciones.
 Vuelva a Compilar y Previsualice

 Dele un mejor diseño al detalle del reporte.

 Vuelva a Compilar y Previsualice
 En la sección Page Header, agregue Current date arrastrando de la

Paleta.

La herramienta le solicitará elegir el formato de la fecha a mostrar. Seleccione uno de

ellos y dé clic en Apply.
 Uso de VARIABLES
Las Variables se caracterizan por calcular datos según el DataSet del

reporte. Su nomenclatura consiste en $V{NOMBRE}
 En sección Page Footer, agregue la variable PAGE_NUMBER para

mostrar número de página.
 En sección Summary, va a mostrar el Total de Vendedores obtenidos.

Para ello, agregue Textos estáticos y la variable REPORT_COUNT
que calcula la cantidad de registros mostrados en reporte, según:
 En sección Title, agregue el logo de la empresa. Para ello, agregue

Image arrastrando de la Paleta.

Busque la imagen deseada y dé clic en Abrir.
 Seleccione la imagen del logo y busque en propiedades Image

Expression. ¿Es un ruta relativa?. No, se trata de una ruta absoluta, la
cual debe cambiar a relativa.
Nota: Para el uso de ruta relativa, es importante que la carpeta images esté en la
misma carpeta donde está el archivo *.jrxml
 Compile y Previsualice .


 Va a añadir filtros de búsqueda al reporte.
Lo primero que hará es modificar la consulta SQL agregando la cláusula WHERE.
Luego, cree un parámetro para utilizarlo en la consulta SQL como dato dinámico.
Creación de parámetro

Uso de parámetro
 Compile y Previsualice .
Le saldrá un PROMT para ingresar el código del distrito, por ejemplo M1.
Resultado de búsqueda con filtro

LABORATORIO 20
Se implementará una nueva versión del reporte que muestre vendedores por cada
Distrito.
Objetivos: Utilizar Report Groups de Jasper
 Se tomará como plantilla base el reporte implementado en laboratorio

anterior.
 Script de Base de datos y demás recursos será encuentran en carpeta
a. Prototipos:


b. Pasos a seguir:
1. Abrir el archivo reporte_simple_2.jrxml ubicado en la carpeta

2. Modifique la consulta SQL para obtener la data requerida.

Según prototipo, va a realizar el agrupamiento por distrito. Por ello, debe obtener el
código de distrito. También, se requiere la descripción del Distrito para mostrarlo como
título de cada grupo.
3. Se actualizan los Fields
4. Compile y Previsualice .
Observe que, aún, no hay diferencia en el resultado.
5. Añada Report Groups
Dé clic derecho al nodo raíz del reporte y seleccione Add Report Group.

Se mostrará un wizard, donde definirá el nombre del grupo y el campo requerido para
agrupar.
En el ejemplo, va a seleccionar el Field CODIGO_DIS.
Luego, dará clic en Siguiente.
Ahora, debe seleccionar las nuevas secciones que se deben añadir al reporte:
Según prototipo se requiere ambas secciones.
 Group header: Mostrar descripción del Distrito

 Group footer: Mostrar el total de vendedores del Distrito

Luego, dé clic en Terminar.
Se observa las nuevas secciones añadidas al reporte.
6. Configure Report Groups
Arrastre el field DESCRIPCION_DIS a la sección Group Header 1.

Dado que solo quiere mostrar su valor, seleccione The field value y dé clic en Ok.
Compile y Previsualice .

Para añadir totales por distrito, arrastre el field CODIGO_DIS a la sección Group
Footer 1.
Dado que necesita calcular el total de vendedores de cada distrito, seleccione The
result of an aggregation function (count) y dé clic en Ok.


7. Finalmente, adecúe el diseño según prototipo.
Nota: Para que un grupo no se muestre dividido por cambio de página, seleccione la
sección Group Header 1 y active el check de la propiedad Keep Together.

LABORATORIO 21
Se implementará un reporte que muestre por cada Distrito el total de vendedores

según su Estado Civil.
Objetivos: Utilizar Report Groups de Jasper
 Script de Base de datos y demás recursos se encuentran en carpeta

 Únicamente, para este ejemplo, se ha añadido la tabla
TB_ESTADO_CIVIL en la base de datos.
a. Prototipos:

b. Pasos a seguir:
1. Abrir el archivo reporte_simple_3.jrxml ubicado en la carpeta

2. Obtenga los datos.
Según el prototipo los datos requeridos, debe organizarse a nivel SQL de esta manera:

Defina la siguiente consulta SQL para obtener la data requerida.
Para obtener los totales por estado civil en la consulta SQL, se realiza el agrupamiento
con el código de Estado Civil. Asimismo, sobre ello, hay que agrupar los resultados
por cada distrito.
Observe que se agregaron al reporte los Fields generados.
3. A nivel del reporte, hay que agregar un Report Group asociado a distrito.

El nombre del grupo será G_DISTRITOS. Luego, seleccioné el Field

DESCRIPCION_DIS y dé clic en Siguiente.
Seleccione ambas secciones y dé clic en Terminar.

4. Configure Report Groups
Arrastre el field DESCRIPCION_DIS a la sección Group Header 1.
Dado que solo quiere mostrar su valor, seleccione The field value y dé clic en Ok.
Adicionalmente, añada un StaticText con el valor “DISTRITO: ”

Para añadir total de vendedores por distrito, arrastre el field TOTAL a la sección
Group Footer 1.

Dado que necesita calcular el total de vendedores de cada distrito, seleccione The
result of an aggregation function (sum) y dé clic en Ok.
Adicionalmente, añada un StaticText con el valor “TOTAL: ”

5. Configuración de la sección Detail
Arrastre los fields DESCRIPCION_EST_CIV y TOTAL a la sección Detail.

6. Finalmente, adecúe el diseño según prototipo.

7. Añada un Gráfico estadístico.
Seleccione el segundo gráfico de barras y dé clic en Ok.

Se mostrará el wizard de Charts, dé clic en Siguiente.
En la ventana Series, dé clic al botón ; seleccione, en la nueva ventana, el field

DESCRIPCION_EST_CIV con double clic.

Finalmente, dé clic en Apply, aparecerá el field, en la ventana Series. Luego, dé clic

en Siguiente.
Ahora, hay que configurar los valores en la ventana Category and Value con los fields
según la siguiente imagen:

Finalmente, dé clic en Terminar.

3.2.1 Integración de Struts 2 y JasperReport
LABORATORIO 22
Se implementará un reporte que se pueda descargar en aplicación web con formulario

de filtros.
.
Objetivos: Integrar Jasper Reports con Struts 2
 Script de Base de datos y demás recursos se encuentran en carpeta

laboratorio 22.
a. Prototipos:
b. Pasos a seguir:
El reporte que quiere configurar, en la aplicación, es el que vio en el laboratorio 20. Sin
embargo, tiene una diferencia: Se le ha quitado la consulta SQL, ya que, en la
aplicación, tiene la responsabilidad de ejecutar SQL en la capa de persistencia. Si
revisa el jrxml, verá que los Fields no se han modificado, eso quiere decir que debe
enviarle al reporte los datos en un listado de objetos que tengan definido los mismos
campos. Para ello, en el ejemplo, utilice un Map.

Según lo explicado, en el párrafo anterior, lo primero que debe hacer es implementar

la consulta SQL con Mybatis.
2. Implementación de capa de persistencia
Consulta SQL
VendedorMapper.xml
Nota: Es obligatorio que el nombre de los campos a almacenar en el hashmap sean

idénticos a los fileds del reporte jasper, de lo contrario el reporte no reconocerá los
campos que le sean enviados.
VendedorMapper.java
3. Implemente capa de negocio.
VendedorService.java

VendedorServiceDAO.java
4. Diseño de la página de reporte:
 Cree el archivo Reporte1.jsp dentro de la ruta /WEB-

INF/paginas/reportes.
 Añada el siguiente código.

5. Implemente el Action para el reporte de Vendedor.
Se implementa la interfaz Preparable para precargar el combo de distritos, ya que es

utilizado en el formulario. Asimismo, se declara el bean Distrito donde se almacenará
el distrito seleccionado.
El método generarReporte1 invocará al servicio para obtener los datos a mostrar en

el reporte.
6. Configure los Action Mapping y el definition asociado.
Struts-reporte.xml

Tiles.xml
7. En menú, añada un enlace que invoque al primer ActionMapping.
Menú.jsp
Listo, hasta aquí, ha implementado una funcionalidad típica de búsqueda, lo único que
falta, aquí, es mostrar la lista de resultados en alguna página. En este caso, dichos
resultados los va a mostrar en un reporte Jasper.
8. Integre Strtus 2 con Jasper.
 Añada librerías (los puede encontrar en la carpeta /recursos/jasper).
 Añada el reporte jasper con sus recursos (imágenes) en la carpeta src.
 Defina ResultType de jasper en el package struts-reporte.

Struts-reporte.xml
 Asimismo, redefina el result del ActionMapping reporte1.
Struts-reporte.xml

ANEXOS

ANEXO
1
SOFTWARE REQUERIDO
Este curso requiere las siguientes herramientas de software:
 Java JDK
 Entorno integrado de desarrollo o IDE
 Servidores de Aplicación
 Base de datos
 Framework Struts 2
 Framework MyIbatis

HERRAMIENTA #1: Java Development Kit

Desde la página de Oracle, descargue la última versión del JDK (Java Development
Kit). Se debe considerar que los “updates” de las versiones son periódicos.
Enlace:
http://www.oracle.com/technetwork/java/javase/downloads/index.html
Para entornos de programación, se requiere el JDK, pero para los de producción basta
con el JRE.
Descargue la última versión del JDK, ejecute el instalador y siga los pasos indicados
en el wizard.

HERRAMIENTA #2: Entorno Integrado de Desarrollo

En un entorno de desarrollo Java, el IDE (Integrated Development Environment ) es la
herramienta de software que permite obtener mayor productividad al programar las
aplicaciones. En el mercado, existen varias opciones disponibles, pero las más
utilizadas y conocidas son las siguientes:
 Eclipse IDE : Sitio web http://www.eclipse.org

 NetBeans : Sitio web http://www.netbeans.org
 JDeveloper : Información disponible en http://www.oracle.com
 Rational Application Developer: Información disponible en http://www.ibm.com
Eclipse IDE:
Primero, descargue el instalador ingresando a la página de Eclipse

(http://www.eclipse.org ), busque la zona de descarga y seleccione la versión Eclipse
IDE for Java EE Developers
Al terminar la descarga, el .ZIP generado se puede extraer en una carpeta cualquiera

(normalmente en la raíz de uno de los discos de la PC).
Se puede crear un acceso directo desde el Escritorio apuntando al archivo eclipse.exe

HERRAMIENTA #3: Servidores de Aplicación

Apache Tomcat
Desde la página de la Fundación Apache ( http://tomcat.apache.org ), se debe obtener

el servidor de aplicaciones Tomcat.
Descargue la versión 7: http://tomcat.apache.org/download-70.cgi
Sólo es necesario el “Core”. Descargue el Windows Service Installer y ejecute el

wizard de instalación.

HERRAMIENTA #4: Motor de Base de Datos

Se necesita un motor de base de datos: En http://www.mysql.com, se puede descargar
la Base de Datos MySQL (versión “Community Server”)
Descargue la versión vigente del MySQL Installer.
Descargue el “Connector” driver JDBC: http://dev.mysql.com/downloads/connector/


Descargue, también, el MySQL WorkBench: http://dev.mysql.com/downloads/tools/

(MSI Installer)

HERRAMIENTA #5: Librerías de Struts 2

Del sitio web de Struts http://struts.apache.org/release/2.3.x/index.html, se obtienen las
librerías del Framework Struts 2.
Se debe escoger una de las opciones de los archivos .ZIP, por ejemplo el “Full
Distribution”.
Luego, se debe extraer el contenido del .ZIP en una carpeta de la PC.

HERRAMIENTA #6: MyIbatis

La página principal se encuentra en http://www.mybatis.org/
Desde la zona de Products, descargue MyBatis 3.

ANEXO
2
GESTIÓN DE PROYECTOS CON
SCRUM
Gestión de proyectos de desarrollo de Software utilizando el marco de trabajo
Scrum.
 Definición y principios de Scrum

 Roles de Scrum
 Elementos y dinámica de Scrum
 Preguntas prácticas de Scrum
 Artefactos de Scrum

DEFINICIÓN Y PRINCIPIOS DE SCRUM

Scrum es un enfoque ágil para el desarrollo de Software. Es importante resaltar el
hecho de que Scrum, como enfoque, ofrece una serie de técnicas, herramientas y
prácticas para llevar a cabo el manejo de proyectos. Debido a ello, no se le considera
un proceso o una metodología, sino más bien, un marco de trabajo.
Scrum se centra en la simplicidad para el manejo de problemas complejos, como es el

caso de los proyectos de desarrollo de Software; es decir, su uso no se extiende
únicamente a este último tópico, sino que es aplicable en muchos contextos diferentes.
Como ya se mencionó antes, Scrum es un marco de trabajo que da soporte a la

innovación, cambios constantes y asegura la entrega de resultados de alta calidad en
tiempos muy cortos; algo que es cada vez más demandado en la industria del
Software y que muchas empresas de talla internacional como IBM, Oracle, Microsoft,
entre muchas otras ya han adoptado.
A pesar de que Scrum no es una metodología, como se ha remarcado previamente, sí

se emplea durante el desarrollo de un proceso; es por ello que se rige de una serie de
principios sólidos como el empirismo, los elementos emergentes y la auto-
organización. Examinaremos en detalle cada uno de estos principios orientados a los
proyectos de Ingeniería de Software.
Empirismo
No es novedad que los proyectos de desarrollo de Software involucren cambios

constantes, en los que muchas veces una versión final de la aplicación difiere de su
concepción inicial. En este caso, el empirismo permite la inspección y adaptación
continua a diferentes situaciones, lo cual permite tomar decisiones en tiempo real y en
base a datos reales. Es decir, se puede responder rápidamente a contextos
cambiantes con eficiencia y eficacia.
Elementos emergentes
Al haber una aproximación al empirismo, se generan consecuencias, las cuales

implican que todas las soluciones y problemas se volverán visibles conforme se vaya
avanzando un proyecto. De este modo, permitiendo que las solucionen emerjan, es
más fácil escoger la más simple y viable para el contexto al cual se esté enfrentando.
Auto-organización
La Auto-organización es un principio importante, pues Scrum se centra en el equipo,

las personas y la comunicación entre ellas para el éxito de un proyecto. La auto-
organización va enfocada, entonces, a la estructura de los equipos que crean un
producto o van a dar solución a un problema. La base de este principio es la
autonomía que se da a los equipos (que deben ser multidisciplinarios) para que
puedan tomar las decisiones necesarias para crear un producto de calidad y gestionar
sus procesos de la mejor manera. No existe organización más adecuada para
gestionar tiempos y recursos que el mismo equipo encargado de desarrollar un
producto.
Priorización
Aunque la Priorización no es un principio clave, Scrum se apoya de este mecanismo

para enfatizar el hecho de que hay temas que siempre son más importantes que otros;

aunque esto sea muy obvio, actualmente, muchos equipos de trabajo quieren hacer
todo el trabajo de manera inmediata perdiendo el foco en las actividades claves o más
importantes. El mecanismo de priorización ayuda a que un equipo sea riguroso y
ordenado, asegurando el éxito del desarrollo de un producto usando Scrum.
Timeboxing
Timeboxing es un mecanismo adicional que permite manejar de manera simple el

manejo de tiempo y la establecimiento de límites para lograr objetivos, algo que aún
ahora es complicado en muchas organizaciones. Esto ocurre muchas veces porque
una organización se imagina todo el sistema completo y junto de una sola vez; en vez
de tomar un problema pequeño pero vital para resolverlo en un periodo de tiempo más
reducido pero que al final de cuentas, dará valor al objetivo o metas establecidas. Con
una solución pequeña pero estable y óptima, será más fácil replicar los mecanismos
de trabajo en los demás problemas que se encuentren; de igual modo, será mucho
más fácil y rápido tomar decisiones. Cabe mencionar que, aunque el timeboxing es un
mecanismo bastante flexible y útil, es también importante respetar los límites de
tiempo establecidos y los compromisos hechos dentro de ese marco de tiempo.
Así pues, Scrum, tiene una serie de principios sólidos sobre los cuales se rige para
lograr el la resolución de un problema, o en un caso más relacionado con los objetivos
de esta carrera: el desarrollo de un producto de Software de calidad. Y al igual que los
principios, Scrum, como marco de trabajo, nos especifica una serie de roles,
elementos y artefactos que facilitan su adopción y aseguran el éxito de su uso.
Roles de Scrum
En un equipo Scrum, se espera la intervención de tres roles principales:
Equipo de desarrollo
El equipo de desarrollo está conformado por todos los individuos necesarios para la
construcción de un producto de Software; cada uno de los miembros de este equipo
son los responsables de la construcción y calidad del producto.
Siguiendo el principio de la auto-organización, el equipo no cuenta con un líder externo

que asigne tareas o determine la forma en que serán resueltos los problemas; sino,
más bien, es el mismo equipo el que determina la mejor forma de trabajar y la mejor
forma de resolver un problema.
Lo recomendable es que un equipo de desarrollo se componga de hasta nueve

personas, cada persona tendrá las habilidades o capacidades necesarias para realizar
el trabajo requerido. Dada esta premisa, se puede decir que un equipo debe ser
multifuncional y no debe haber un experto exclusivo de determinada área, sino, más
bien un equipo que tenga todo a su alcance para colaborar y asegurar el éxito.
Como equipo de desarrollo, hay tres responsabilidades esenciales que no son

transferibles a ningún otro rol en Scrum. La primera es proveer las estimaciones del
esfuerzo requerido para cada una de las características del producto que se va a
desarrollar. La segunda involucra el compromiso al inicio de cada etapa de desarrollo
(Sprint) para construir el conjunto de características prometido en el tiempo
establecido. Y finalmente, es responsable de la entrega del producto terminado al
finalizar cada Sprint.

Product Owner
Producto Owner es la persona responsable del éxito del producto desde el punto de
vista de los stakeholders (sponsors, usuarios del sistema, etc.). Como tal, tiene
responsabilidades como determinar la visión del producto y hacia dónde va el equipo
de desarrollo. De igual modo, debe saber manejar las expectativas de los stakeholders
y reunir los requerimientos. Además, debe determinar y conocer en detalle las
características funcionales y gestionar el plan de “reléase”, es decir las fechas en las
cuales se entrega un producto y con qué características contará para cada fecha.
Asimismo, debe determinar las prioridades de cada característica del producto o
cambiarla según sea el caso. Dadas estas funciones, el Product Owner es el único rol
capaz de aceptar o rechazar el producto construido al final de cada Sprint y proveer el
feedback o retroalimentación necesaria para mejorar el proceso (evolutivo).
ScrumMaster
ScrumMaster es la persona que sirve como Coach del equipo y ayuda a alcanzar su
máximo nivel de productividad.
Un ScrumMaster no es un jefe, sino un líder al servicio de los demás, facilitador y que

acompañe al equipo de trabajo en su día a día, garantizando así de que todos,
incluyendo al Product Owner, comprendan y utilicen Scrum de la manera correcta. Por
esta razón, un ScrumMaster debe ser un experto en Scrum; de modo que pueda
facilitar su uso en el transcurso del tiempo. Además, tiene la responsabilidad de que
todos asistan a tiempo a las reuniones diarias, revisiones y retrospectivas. Un
ScrumMaster debe velar porque el equipo sea eficiente y si hay algún impedimento,
ayudar a su remoción y asegurar la cooperación y comunicación dentro del equipo.
Asimismo, debe estar al corriente del progreso de las actividades del equipo de
desarrollo, el surgimiento de nuevas tareas o cambios para así poder ayudar y servir
de la mejor manera.
Como se puede apreciar en este rol, el ScrumMaster como coach debe detectar
problemas y conflictos interpersonales y ayudar a que el equipo, como unidad auto-
organizada, pueda solucionar problemas de este calibre. Si un ScrumMaster no puede
solucionar el problema en cuestión, puede, eventualmente, involucrar a niveles más
altos de la gerencia.
Cabe mencionar que el ScrumMaster no necesariamente puede ser un desarrollador,

pero si es necesario que tenga el conocimiento técnico necesario para poder contribuir
de manera eficiente en el equipo. Si bien un ScrumMaster puede cubrir el rol de
desarrollador, no siempre es recomendable hacerlo pues puede llegar a exceder la
disponibilidad y sus roles pueden entrar en conflicto.
Elementos y dinámicas de Scrum

El trabajo con Scrum involucra una mínima cantidad de elementos formales para poder
ejecutar un proyecto de desarrollo, en esta sección se mencionarán los elementos
formales, así como las dinámicas empleadas en este marco de trabajo:
Product Backlog
Product Backlog es el principal elemento de Scrum, conocido también como “pila del
producto” ya que contiene una lista de ítems llamados PBIs (Product Backlog Items)

que no son ni más ni menos que las características del producto a construir. Todos los
PBIs deben estar priorizados y actualizados; esta función la lleva a cabo el Product
Owner como se mencionó anteriormente en la sección de roles.
Cabe resaltar que aunque el Product Owner es quien tiene la última palabra sobre la
prioridad final de los ítems del Product Backlog, el equipo de desarrollo puede hacer
sugerencias o recomendaciones de acuerdo a los aspectos que considere
convenientes (carga de trabajo, dificultad de las tareas, curvas de aprendizaje, etc.).
Como ya se ha enfatizado, el Product Backlog es una lista de elementos ordenados y

priorizados, esta priorización se realiza de múltiples formas, siendo tres de ellas las
más utilizadas en el ámbito de la gestión de proyectos de desarrollo de Software:
priorización por valor de negocio de cada ítem, priorización por retorno de la inversión
de cada ítem, y prioridad según la importancia y riesgo de cada ítem.
Para el caso de la priorización por valor de negocio, se entiende que un ítem

priorizado bajo esta modalidad tiene relevancia o es vital para los objetivos del negocio
de una empresa o de los stakeholders. Por ejemplo, para un sistema de finanzas, las
características del sistema vitales y prioritarias deberían estar relacionadas con la
facturación y cobranzas así como la entrega de reportes vitales para la toma de
decisiones.
En el caso de la priorización por retorno de inversión, se toma en cuenta el beneficio

económico al que está sujeto una característica determinada del sistema, dicho
beneficio será calculado en base a la ganancia que se obtiene por sobre la inversión
que involucra la ejecución o realización de un ítem. La fórmula matemática es sencilla
y se puede representar a este valor como “ROI” (Return of investment) que se resume
en: valor de negocio / costo.
Finalmente, para el caso de prioridades según importancia y riesgo, se toma en cuenta

el riesgo que puede tener la realización de un ítem por sobre otro y el impacto de las
consecuencias. Este mecanismo de priorización es más que nada complementario a
los dos antes mencionados y su objetivo es mitigar los riesgos de forma implícita; de
modo que se logren construir primero las funcionalidades con mayor riesgo asociado y
dejando las que poseen menor riesgo para etapas posteriores.
Sprint Backlog
Sprint Backlog es un elemento de Scrum que se deriva exclusivamente del Product

Backlog y contiene las características o ítems a desarrollar durante un periodo de
tiempo determinado. Esto quiere decir que un Sprint Backlog toma los elementos
priorizados de un Product Backlog, con la salvedad de que tiene elementos
adicionales como la lista de tareas que involucra el realizar un determinado ítem, así
como el estado de cada una de ellas, que por lo general se divide en: TODO
(pendiente), WIP (en progreso derivado de Work in Progress) y DONE (terminado).
Historia de usuario
Historia de usuario es una dinámica la cual permite expresar de una manera rápida y
entendible la característica de un producto que se quiere implementar. Por lo general,
los PBIs deben ser expresados como historias de usuario para tener un alcance y
descripción más claros que facilitarán el desarrollo del equipo de trabajo. Asimismo,
pueden incluir criterios de aceptación, los cuales indicarán si una historia de usuario
cumple con los requisitos para ser considerada terminada (Definition of Done).

Para expresar una historia de usuario como tal es necesario tener en claro cómo
elaborar el enunciado, el cual está compuesto por los siguientes elementos: Rol,
Acción y Resultado. El enunciado no describe detalles de cómo se va a ejecutar la
acción que necesita el usuario.
Para una mejor clasificación y organización puede añadirse un código a cada historia,
para ayudar a su identificación única dentro del proyecto (actualmente hay
aplicaciones como ScrumWise o Jira que permiten gestionar todos los artefactos y
dinámicas que se explican en este anexo).
Para entender mejor cada uno de los elementos que componen una historia de
usuario, se explicarán en detalle en qué consisten:
 Identificador (ID) de la historia: Código que identifica de manera única a la

historia en el Proyecto que se esté desarrollando. El formato debe ser elegido
por el equipo (o definido por la aplicación en su defecto).
 Rol: Es el rol que está desempeñando el usuario cuando utiliza la funcionalidad
que se está describiendo. Debe ser lo más específico posible.
 Característica / Funcionalidad: Representa la función que el rol quiere o
necesita hacer en el producto de Software que se está desarrollando. Puede
diferenciarse entre acciones obligatorias u opcionales.
 Resultados: Lo que el rol necesita lograr al ejecutar la acción. Este es el
resultado de ejecutar la acción desde el punto de vista del rol. Este punto
puede ser opcional, pues la historia puede documentarse sólo con la definición
del rol y la acción (sin definir la consecuencia).
Una estructura base de cómo deberían relacionarse los elementos mencionados en un

enunciado formal es el siguiente:
[ID] - Yo como un [Rol], necesito [Descripción de la funcionalidad], con la finalidad de

[Descripción de la consecuencia].
Un ejemplo, aplicado al campo del desarrollo de Software puede ser el siguiente:
[FREQ01] - Yo como un estudiante de Cibertec, necesito matricularme en los cursos

correspondientes de la carrera, con la finalidad de tener un registro de mi horario y los
créditos que debo pagar.
Sprint (Iteración)
Los productos de Software se desarrollan de manera incremental e iterativa; el

enfoque ágil no discrepa de este modo de trabajo, por ello Scrum incluye los Sprints
como parte vital del proceso de construcción del producto.
Todo producto, como bien se remarca, se construye en incrementos funcionales

entregados en periodos cortos para obtener feedback frecuente. Scrum recomienda
que estos incrementos (duración del Sprint) duren entre 1 y 4 semanas; siendo 2 o 3 el
periodo de tiempo más habitual. La definición de un Sprint es crucial para definir el
ritmo de trabajo; ya que una vez definido, lo ideal es mantener dicha duración de
manera constante a lo largo del desarrollo del producto; es decir, la duración de una
iteración o Sprint no debe variar una vez que se ha establecido.
Pese a lo antes mencionado; el equipo Scrum por mutuo acuerdo puede decidir en
probar con iteraciones más largas o cortas. Esta decisión deberá estar respaldada por
razones bien fundamentadas como negocio cambiante, requerimientos ambiguos o

desconocidos, etc. Lo importante es tener claro que el ritmo de trabajo definido por el
Sprint ayudará a una mejor previsibilidad y a obtener, al final del periodo, un
incremento funcional potencialmente entregable.
Incremento funcional potencialmente entregable
El Incremento funcional potencialmente entregable es el resultado de cada Sprint. Se

dice que es incremento funcional porque es una característica nueva (o mejorada) de
un producto que está siendo construido de manera evolutiva y que da valor al usuario.
El producto crece con cada Sprint que pasa. De igual modo se dice que es
potencialmente entregable, puesto que cada una de estas características se encuentra
lo suficientemente validada y verificada para poder ser entregada a usuarios finales.
Sprint Planning
El Sprint planning es la reunión de planificación del Sprint y se realiza antes de

empezar un Sprint. En esta reunión se establecen los acuerdos y compromisos entre
el equipo de desarrollo y el Product Owner sobre el alcance del Sprint a ejecutar. Lo
recomendable es dedicar un día a este planeamiento para lograr definir el qué y cómo
se van a trabajar las historias de usuario (ítems del Product Backlog que están
delimitados para un Sprint en un Sprint Backlog).
Daily Meeting o Daily Scrum
El Daily Meeting o Daily Scrum son las reuniones diarias que deben realizarse al
empezar la jornada de trabajo (es lo recomendable). Estas reuniones son parte
fundamental del marco de Scrum pues uno de los beneficios de Scrum que se
encuentra en sus principios es el incremento de la comunicación dentro de un equipo
de trabajo. Esto facilita la coordinación e interacción entre los miembros y refuerza el
conocimiento actual que todos tienen, aparte de conocer las dependencias de las
actividades que realizan.
Los tres objetivos fundamentales de las reuniones diarias son: incrementar la

comunicación, hacer explícitos los compromisos asumidos y poder saber qué
impedimentos existen para poder solucionarlos.
Estas reuniones aunque pueden parecer complejas, no deberían tomar más de 15

minutos y es primordial que todo el equipo y el ScrumMaster se encuentren presentes
para poder responder tres principales preguntas:
- Qué hice ayer

- Qué haré hoy
- ¿Tengo algún impedimento para continuar con mis actividades?
El fin de responder a estas tres preguntas no es reportar el estado de avance al

ScrumMaster como si fuese un jefe. Por el contrario, ayuda a los miembros del equipo
estar enterados de lo que ocurre dentro de su entorno. Asimismo, ayuda al
ScrumMaster a remover impedimentos en caso exista alguno.
Cabe mencionar que aunque lo requerido en las reuniones son al equipo de trabajo y
al ScrumMaster; los otros roles como Product Owner o Stakeholders pueden participar
si lo consideran conveniente; no obstante, a menos que sea estrictamente necesario,
su participación es en calidad de expectadores u observadores; su participación cobra
más importancia en la reunión de revisión de producto, la cual se analizará a
continuación.

Reunión de revisión del producto
La Reunión de revisión del producto es una reunión que se realiza al finalizar cada
Sprint y tiene como objetivo exponer el entregable producido durante el periodo de
trabajo para obtener la aceptación o rechazo del Product Owner respecto a las
características construidas. Además, esta reunión sirve como dinámica clave para
recibir “feedback” por parte del Product Owner o los Stakeholders y hacer los ajustes
necesarios en la siguiente iteración.
Reunión de retrospectiva
La Reunión de restrospectiva es un método empírico para la retrospección del equipo

de trabajo en sí y lograr la mejora continua. En esta reunión, el equipo analiza y
reflexiona sobre su modo de trabajo durante un Sprint determinado, así como los
acontecimientos que pudieron sorprenderlos o “bloqueadores” que causaron demoras
al momento de ejecutar sus actividades; todo ello con el fin de mejorar sus prácticas.
Por lo general, esta reunión se lleva a cabo luego de la revisión del producto en un
espacio en el cual el equipo puede expresarse libremente y resolver problemas,
exponer experiencias y establecer bases para un mejor desempeño en el siguiente
Sprint.
Burndown Chart
Burndown Chart es una representación gráfica del trabajo que se debe realizar en un
determinado periodo de tiempo y del trabajo que se ha realizado también; de modo
que se pueda apreciar el progreso del trabajo durante un Sprint. Su representación se
realiza a través de un diagrama de dos dimensiones, en el cual el eje vertical
representa las actividades a realizar y el eje horizontal representa al tiempo.
El Burndown Chart es un componente útil para la visualización gráfica y estadística del

avance de un proyecto de Software a lo largo de todos sus Sprints. Así como para la
comparativa entre el tiempo estimado de las tareas versus el tiempo real que tomaron,
generando así métricas importantes para la toma de decisiones en reuniones de
retrospectiva.
Scrum Task Board
Dentro de los elementos opcionales de Scrum, está el panel o matriz de estado de

actividades, cuya utilidad es representar de manera más gráfica el Sprint Backlog y las
tareas que abarcan las historias de usuario definidas para dicha iteración.
En esta tabla o panel, se suele hacer separación de columnas de acuerdo a los

siguientes conceptos: Historia de Usuario / Actividad, TO DO (por hacer), IN
PROGRESS (en progreso / desarrollo), TO VERIFY o TO TEST (pendiente de pruebas
o validaciones) y DONE (terminado).
Por lo general, la columna “TO VERIFY” puede ser obviada, ya que se utiliza para
fines de análisis de calidad o por los encargados de pruebas para monitorear su
trabajo. Lo más frecuente o más usado para delimitar el avance de tareas es “TO DO”,
“IN PROGRESS” o “DONE”.
Como bien se mencionó, este artefacto es una representación más gráfica del Sprint
Backlog que facilita a un miembro del equipo de trabajo administrar sus tareas de
manera ordenada y a los otros roles poder ver el estado de avance. Este artefacto

puede representarse en cualquier tablero o pizarra utilizando “post-its” o notas

adhesivas que tengan como contenido las tareas que se ven afectas al progreso de un
Sprint.
Cabe mencionar que el Sprint Backlog puede tener una tabla de estados similar que
está adjunta al documento o incluída en el mismo documento como se podrá ver más
adelante en la sección “Artefactos de Scrum”.
Preguntas prácticas de Scrum

¿Por qué se dice que Scrum es un “framework” o marco de trabajo y no una
metodología?
Una metodología hace referencia a una serie de procedimientos que deben realizarse
para alcanzar un determinado objetivo. Scrum, como tal, no define ningún
procedimiento o camino de éxito. Scrum brinda herramientas, técnicas, artefactos,
roles y dinámicas que se agrupan en un conjunto de buenas prácticas adoptables por
cualquier organización para cualquier tipo de proyecto (no necesariamente Software).
Es por ello que Scrum no se considera a sí mismo una metodología, sino más bien un
marco de trabajo que es resultado de la experimentación de muchas organizaciones
que han alcanzado objetivos de manera eficiente.
¿Cuáles son los criterios a seguir para priorizar el Product Backlog?
Existe un criterio fundamental para la priorización del Product Backlog: Valor al

negocio. Un PBI (ítem de Product Backlog de su traducción del inglés) se determina
por qué tanto valor aporta al negocio. Si bien la facturación es la parte que puede
parecer la de más valor, son las actividades de giro de negocio las que realmente
aportan valor al negocio. Por ejemplo, en una entidad educativa, podría tomarse como
prioridad la matrícula de los alumnos; ya que es un proceso muy difícil de manejar
manualmente; demanda de recursos humanos, recursos monetarios y mucho tiempo,
por ello, automatizar esta actividad sería de mucha ventaja y se reflejaría en el ahorro
de todos los recursos empleados. Para un banco, por ejemplo, las transacciones y
movimientos entre entidades o personas naturales sería el principal elemento a
considerar; mientras que para una clínica, el registro y seguimiento de pacientes sería
lo primordial.
No obstante, son los stakeholders (clientes o auspiciadores) los que realmente definen
el sentido de urgencia de las características que deben priorizarse o no. Es por esta
razón, que la comunicación con el “Product Owner” debe ser bastante clara y muy
frecuente para asegurarse de que se estén realizando las actividades que el cliente
considere más urgentes. Pero, por lo general, se toman en cuenta las actividades que
representan un beneficio máximo para la empresa o entidad interesada; es justamente
el beneficio o característica que brinda el mayor retorno de inversión (ROI) el criterio
principal para la priorización de los elementos en un Product Backlog.
¿Qué pre-condiciones deben existir para elaborar el Sprint Backlog

correspondiente a partir de un Product Backlog y qué se debe tomar en cuenta?
Es importante mencionar y resaltar el hecho de que un Product Backlog NO se

transforma en un Sprint Backlog. Un Product Backlog es constante y sólo puede ser
alterado por el Product Owner para volver a priorizar elementos (PBIs) de acuerdo a
las necesidades del negocio. Los Sprint Backlogs se derivan del Product Backlog

antes de iniciar un Sprint (durante el Sprint Planning). Para poder elaborar el Sprint
Backlog, es necesario tener priorizado el Product Backlog, de éste último se extraen
las características o elementos que se desarrollarán o en los que el equipo trabajará
durante el periodo de tiempo establecido (Sprint). Cada vez que está por iniciar un
Sprint, se debe realizar el planeamiento como es debido para tener el Sprint Backlog,
es decir, por cada Sprint que se realice, se debe tener un Sprint Backlog.
De lo antes mencionado, podemos decir que, mientras que el Product Backlog es

persistente (susceptible de cambiar en el tiempo); un Sprint Backlog está presente
para el Sprint correspondiente; generando un nuevo artefacto en cada iteración. Para
poder generar este documento, es requisito indispensable que el Product Backlog se
encuentre priorizado.
¿Cuál es la duración máxima del Daily Meeting y qué temas debería abarcar?
Una de las dinámicas más importantes para mantener vivo el concepto de Scrum es el
Daily Scrum o Daily Meeting. No obstante, a pesar de ser una dinámica muy
importante, su duración no debería exceder los 15 minutos; ya que esta dinámica sólo
está presente para dar un estado del trabajo que se viene realizando diariamente y
reportar los impedimentos que pueden estar obstruyendo el avance de alguna tarea o
característica necesaria del sistema.
Muchos equipos, tienden erróneamente a entrar en detalle de sus impedimentos

durante esta reunión, lo cual no es lo recomendable por Scrum. El marco de trabajo
nos indica que en esta reunión sólo se comunicará el estado del avance y, de existir,
se mencionará (sólo se mencionará) el impedimento. Todos los impedimentos serán
anotados por el Scrum Master quien es el encargado de tener una reunión o
conversación con el miembro del equipo que tiene el impedimento, entre eambos (o
solicitando la ayuda de algún miembro del equipo con experiencia en el tema) deberán
remover el impedimento. Esta reunión es aparte al Daily Scrum; el objetivo es que el
Daily Scrum no se expanda demasiado y quite tiempo de trabajo valioso para el
desarrollo de tareas.
Artefactos de Scrum
De acuerdo a todo lo antes expuesto, en la siguiente sección se presentan plantillas de

los documentos o artefactos más importantes para llevar a cabo el seguimiento de un
proyecto basado en el marco de trabajo Scrum, en este caso, el Product Backlog y el
Sprint Backlog.
Product Backlog

Sprint Backlog
ID Historia de usuario Prioridad Esfuerzo Actividades – Estado de Estado

actividad general
FREQ001 Yo, como cliente quiero Crear página HTML de
registrarme en el portal registro DONE
de ventas Web para 1 5 Crear hoja de estilos de
tener una cuenta de acuerdo a los colores
usuario y realizar de la empresa DONE
compras. Aplicar estilos a la WIP
página HTML DONE
Crear hipervínculos y
flujos de navegación WIP
Desplegar página en
servidor TODO
FREQ002 Yo, como cliente quiero Crear página HTML de
agregar artículos en un listado de productos.
carrito de compras a DONE
través de la Web para 1 13 Implementar DTOs y WIP
llevar registro y cuenta DAOs para gestionar el
de lo que voy a comprar. listado de productos
disponibles. WIP
Scrum Task Board

Burndown Chart

Manual 2017-I 05 Desarrollo de Aplicaciones Web I (CI) (0265)

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Manual 2017-I 05 Desarrollo de Aplicaciones Web I (CI) (0265)

Diunggah oleh

Hak Cipta:

Format Tersedia

Desarrollo de

CARRERAS PROFESIONALES CIBERTEC

1.1 Tema 1 : Fundamentos 11

Diseño e implementación de reportes con

3.2 Tema 6 : Proyecto Plantilla 229

3.2.1. : Integración de Struts 2 y JasperReport 229

CIBERTEC CARRERAS PROFESIONALES

CARRERAS PROFESIONALES CIBERTEC

Desarrollo de aplicaciones web I, pertenece a la línea de Programación y Desarrollo

El contenido del manual es de carácter académico y su alcance es servir como

El manual ha sido diseñado bajo la modalidad de unidades de aprendizaje, las que se

El curso es eminentemente práctico y se desarrolla íntegramente en laboratorio. En

CIBERTEC CARRERAS PROFESIONALES

CARRERAS PROFESIONALES CIBERTEC

Desarrollo de Aplicaciones Web I

Framework MVC Framework de Reportes

CIBERTEC CARRERAS PROFESIONALES

CARRERAS PROFESIONALES CIBERTEC

 Los alumnos implementan una aplicación web básica utilizando las

CIBERTEC CARRERAS PROFESIONALES

CARRERAS PROFESIONALES CIBERTEC

RELEASE 2.3.X - GUIAS

RELEASES AND VERSION NOTES

CIBERTEC CARRERAS PROFESIONALES

Se muestra, a continuación, el esquema básico de la arquitectura MVC implementada

a. A través de un navegador, se genera un request.

Una característica típica del View de Struts 2 es el uso de unos componentes

CARRERAS PROFESIONALES CIBERTEC

El ciclo de vida, en Struts 2, funciona básicamente de la siguiente manera:

a. El Servlet Container (Tomcat) recibe un request de tipo HttpServletRequest.

CIBERTEC CARRERAS PROFESIONALES

f. El ActionInvocation determinará cuál es el Result asociado al retorno del

CARRERAS PROFESIONALES CIBERTEC

Se revisarán los proyectos Aplicación_01 y struts2-blank.

1.1.1.1 Componentes principales

Los filtros son el punto de partida del procesamiento de un HttpServletRequest

Su ejecución se da antes y después de ejecutar el método de procesamiento de un

Permiten al desarrollador encapsular funcionalidad común y reutilizable que se pueda

Struts 2 tiene una serie de Interceptors implementados para su uso en el desarrollo,

CIBERTEC CARRERAS PROFESIONALES

personalizar dicho orden e, inclusive, definir nuevos Interceptors según la necesidad

El Framework provee diferentes Result-Types nativos que implementan la interfaz

Action Invocation determina cómo se ejecutará el Action invocado por el request

CARRERAS PROFESIONALES CIBERTEC

1.1.1.2 Componentes y Lenguajes de Soporte

Action Context es el contexto en el cual se ejecuta el Action, es decir, es la zona de

Objetos de apoyo al renderizar JSP, por

Objetos del Modelo Cuando Action es de tipo Model Driven

Action ejecutado y todas sus variables.

Referidos a Scopes tales como request,

El acceso a dichos objetos se puede dar según lo siguiente:

 En Clases Action, con la siguiente instrucción:

 En Templates, al utilizar Tags de Struts y/o el lenguaje de

CIBERTEC CARRERAS PROFESIONALES

El Object-Grap Navigation Language es un lenguaje de Expresiones que, en Struts

 Root: Para acceder directamente a variables de Action.

 Objects: Para acceder a objetos que no están en el Root por

CARRERAS PROFESIONALES CIBERTEC

1.1.2 Configuración Básica

Los componentes de Struts se configuran en archivos XML o con Anotaciones.

Para la configuración en archivos XML, se tiene lo siguiente:

a. Web Deployment Descriptor: web.xml

b. Archivo de Configuración Base: struts-default.xml

Contiene configuración, por defecto, de componentes de Struts 2(result types,