Académique Documents
Professionnel Documents
Culture Documents
Ingeniería en Informática
Plataformas de desarrollo de
aplicaciones Web orientadas a
componentes reutilizables
Padrón: 81338
Profesores:
AGRADECIMIENTOS..........................................................................................................1
1. INTRODUCCIÓN .............................................................................................................2
Aplicaciones Web ............................................................................................................2
Ejemplos......................................................................................................................3
Tecnologías.................................................................................................................3
Primera generación – CGI ......................................................................................4
Scripting ..................................................................................................................4
Plataformas de desarrollo Web ...............................................................................5
Web 2.0...................................................................................................................6
Ventajas ......................................................................................................................6
Desventajas.................................................................................................................7
Aplicaciones Enterprise ...............................................................................................7
Definición ................................................................................................................7
Características ........................................................................................................8
El problema .....................................................................................................................9
Carácter del problema ...............................................................................................10
Motivación para resolverlo.........................................................................................10
Pasos a seguir...........................................................................................................11
Criterios de éxito .......................................................................................................11
2. ESTADO DE LA CUESTIÓN .........................................................................................12
Presentación de plataformas a comparar......................................................................12
Experiencia................................................................................................................14
Características generales..........................................................................................14
Model 2 .................................................................................................................15
La aparición de Model 2........................................................................................15
Usando frameworks ..............................................................................................16
Características particulares .......................................................................................17
Struts.....................................................................................................................17
JSF........................................................................................................................19
WebWork ..............................................................................................................21
Tapestry ................................................................................................................22
Análisis teórico ..............................................................................................................25
Criterio de evaluación................................................................................................25
Grillas/Tablas ........................................................................................................25
Soporte para Ajax .................................................................................................25
Bookmark ..............................................................................................................25
Validación..............................................................................................................25
Testeabilidad.........................................................................................................25
Post y redirección..................................................................................................26
Integración con herramientas de Inversión de Control..........................................26
Internacionalización ..............................................................................................26
Decoración de páginas .........................................................................................26
Herramientas.........................................................................................................26
Marketing ..............................................................................................................26
Componentes reutilizables ....................................................................................26
Adaptación de nuevos recursos a un equipo de trabajo .......................................26
Comunidad............................................................................................................27
Madurez de la tecnología ......................................................................................27
Markup estático y dinámico...................................................................................27
Mapeo de requests a lógica de negocio................................................................27
Acceso a recursos.................................................................................................27
Navegación de páginas.........................................................................................27
Wizards .................................................................................................................28
Programación “en el molde” ..................................................................................28
Modelo de la capa de Presentación ......................................................................28
Análisis de herramientas en estudio..........................................................................28
1-Struts .................................................................................................................28
Lógica de navegación entre páginas ...................................................................29
Binding entre java y HTML ..................................................................................31
Internacionalización.............................................................................................32
Validación de entradas ........................................................................................33
Independencia del motor de visualización...........................................................34
Maquetación........................................................................................................35
2-Tapestry .............................................................................................................35
Transparencia en la construcción de las vistas ...................................................35
Binding entre Java y HTML .................................................................................36
Manejo de eventos ..............................................................................................37
Construcción de componentes ............................................................................38
Validación de entradas ........................................................................................38
Internacionalización.............................................................................................39
3-JSF ....................................................................................................................39
Lógica de navegación entre páginas ...................................................................40
Binding entre la vista y los beans de negocio......................................................41
Manejo de Eventos..............................................................................................42
Internacionalización.............................................................................................43
Validación de entradas ........................................................................................44
Independencia del dispositivo de presentación ...................................................46
Construcción de Componentes ...........................................................................46
Evaluación de características....................................................................................46
Análisis de los datos obtenidos .............................................................................60
3. DEFINICIÓN DEL PROBLEMA .....................................................................................62
El Problema ...................................................................................................................62
4. SOLUCIÓN PROPUESTA .............................................................................................65
La Solución....................................................................................................................65
Arquitectura ...............................................................................................................67
configuration..........................................................................................................67
persistence............................................................................................................68
predicates..............................................................................................................68
messages..............................................................................................................68
constants...............................................................................................................68
closures.................................................................................................................68
models ..................................................................................................................68
mail .......................................................................................................................69
reports ...................................................................................................................69
context ..................................................................................................................69
security..................................................................................................................69
writers ...................................................................................................................69
utils........................................................................................................................69
bo ..........................................................................................................................70
web .......................................................................................................................70
Componentes visuales ..............................................................................................70
Introducción...........................................................................................................70
Pages ....................................................................................................................71
Binding ..................................................................................................................73
Layouts .................................................................................................................74
Containers.............................................................................................................79
Validation scope....................................................................................................80
Group ....................................................................................................................83
Fieldset .................................................................................................................83
Actions ..................................................................................................................83
Inputs ....................................................................................................................84
Palette ...................................................................................................................86
Menú .....................................................................................................................87
Table .....................................................................................................................87
Funcionamiento .........................................................................................................90
Ciclo de vida..............................................................................................................90
Patrones utilizados ....................................................................................................93
Front Controller. ....................................................................................................93
MVC ......................................................................................................................94
Template View.......................................................................................................96
Composite .............................................................................................................97
Command..............................................................................................................99
Builder .................................................................................................................101
Domain Model .....................................................................................................101
Query Object .......................................................................................................102
Repository ...........................................................................................................103
5. RESULTADOS O VERIFICACIÓN EXPERIMENTAL..................................................104
Casos de aplicación ....................................................................................................104
“BugMetric”..............................................................................................................104
Descripción .........................................................................................................104
Requerimientos ...................................................................................................104
Casos de uso ......................................................................................................105
Arquitectura.........................................................................................................105
Flujo de páginas..................................................................................................109
Conclusiones.......................................................................................................109
“Sistema de Coordinación Docente”........................................................................110
Descripción .........................................................................................................110
Conclusiones.......................................................................................................110
6. CONCLUSIONES Y FUTURAS LÍNEAS DE INVESTIGACIÓN ..................................111
6.1 Conclusiones .........................................................................................................111
Navegación de páginas......................................................................................111
Wizards ..............................................................................................................111
Adaptación de nuevos recursos a un team ........................................................111
Programar en el “molde” ....................................................................................112
Adaptación a cambios en UI ..............................................................................112
Mapeo de request a la lógica de negocio...........................................................112
Dificultades en la separación de capa de presentación y lógica de negocio......112
Incompatibilidad de navegadores.......................................................................113
6.2 Integración con otros trabajos ...............................................................................113
6.3 Mejoras futuras......................................................................................................113
7. BIBLIOGRAFÍA............................................................................................................116
8. ANEXOS......................................................................................................................118
Contextos de aplicación ideal ......................................................................................118
1-JSF.......................................................................................................................119
2-Struts....................................................................................................................121
3-Tapestry ...............................................................................................................122
4-WebWork .............................................................................................................124
Índice de figuras
AGRADECIMIENTOS
A mi familia por su apoyo durante todas las largas noches pasadas leyendo y escribiendo.
A mi novia Daniela por estar conmigo y entender mi frase “perdón pero tengo que ir a
hacer Tesis”.
A mis amigos, los ingenieros Carlos Curotto y Pablo Ruggia por ser revisores de este
trabajo.
Gracias.
1. INTRODUCCIÓN
Hacia el final se presentarán las conclusiones así como también las posibles futuras
líneas de investigación.
Se incluye en el trabajo una integración con otros dos trabajos de esta Facultad: por un
lado se utiliza un framework de persistencia desarrollado como Trabajo Profesional por los
Ingenieros Carlos Curotto y Pablo Díaz; por otro lado la implementación del modelo
obtenido como solución se utilizó como base en el Trabajo Profesional de los alumnos
Diego de Paz Sierra y Sebastián Marucci.
Aplicaciones Web
En los primeros días de la Web, los sitios Web consistían de páginas estáticas,
permitiendo una interacción limitada con el usuario. Al comienzo de los años 90, estas
limitaciones fueron superadas cuando los servidores Web fueron reemplazados para
permitir comunicaciones a través del desarrollo de fragmentos de código que eran
ejecutados del lado del servidor. A partir de entonces las aplicaciones dejaron de ser
estáticas y solamente editadas por aquellos “gurúes” del HTML y se permitieron a
usuarios normales interactuar con las aplicaciones por primera vez.
Este fue un paso fundamental para llegar a la Web que hoy en día conocemos. Sin la
interacción no existiría el comercio electrónico (Ej.: Amazon.com), el Web-mail (Ej.:
Gmail), Internet-banking, blogs, forums o comunidades online.
Ejemplos
• Intranets empresariales.
Tecnologías
Scripting
Los desarrolladores Web comenzaron entonces a utilizar lenguajes de script , como ser
JavaScript o PHP para resolver esos problemas. Básicamente los lenguajes de script son
ejecutados en el servidor Web y como son no compilados son desarrollados e
implementados más fácilmente.
• Son más lentos en comparación con los lenguajes compilados (a veces hasta 100
veces más lentos).
• Es difícil (no imposible) escribir aplicaciones de múltiples capas porque en general las
capas de presentación, aplicación y datos residen en la misma máquina, limitando de
esta forma la escalabilidad y seguridad.
externos.
Los lenguajes de script incluyen, ASP, Perl, Cold Fusion y PHP. De cualquier manera,
muchos de esos podrían ser considerados como lenguajes interpretados híbridos, en
particular las últimas versiones de PHP y Cold Fusion.
Una vez que los lenguajes de script alcanzaron los límites de performance y escalabilidad,
los proveedores más grandes evolucionaron hacia la plataforma de Sun J2EE y a la de
Microsoft .NET.
• J2EE
Una de las desventajas de J2EE es que posee una curva de aprendizaje importante, lo
que provoca una difícil inserción de diseñadores Web y programadores en sus
primeros pasos.
• .NET
Web 2.0
El concepto original de la Web (en este contexto, llamada Web 1.0) eran páginas estáticas
HTML que no eran actualizadas frecuentemente. El éxito de las punto-com dependía de
webs más dinámicas (a veces llamadas Web 1.5) donde los CMS servían páginas HTML
dinámicas creadas al vuelo desde una actualizada base de datos. En ambos sentidos, el
conseguir hits (visitas) y la estética visual eran considerados como unos factores muy
importantes.
Los propulsores de la aproximación a la Web 2.0 creen que el uso de la Web está
orientado a la interacción y redes sociales, que pueden servir contenido que explota los
efectos de las redes con o sin crear webs interactivas y visuales. Es decir, los sitios Web
2.0 actúan más como puntos de encuentro, o webs dependientes de usuarios, que como
webs tradicionales.
Ventajas
• Bajos costos.
• La información es accesible para una gran audiencia en cualquier lugar del mundo.
• Compatibilidad multiplaforma.
Desventajas
• Riesgos de seguridad.
Aplicaciones Enterprise
Definición
Características
El problema
El desarrollo de aplicaciones Web presenta una serie de dificultades con las que todos los
equipos de trabajo se enfrentan. A continuación se presentan las principales:
En el presente trabajo se pretenden resolver distintos problemas utilizando como eje las
siguientes pautas:
Pasos a seguir
Para esto se determinará un conjunto de características con las que se compararán las
diferentes plataformas. Esta comparación será la entrada que se utilizará para diseñar y
construir la solución objetivo de la tesis.
Criterios de éxito
En base a la motivación del trabajo, sería ideal lograr una plataforma que resuelva todos o
la mayoría de los problemas presentados y que sea posible extenderla en un futuro ante
la aparición de nuevos problemas o actualizarla a las nuevas tecnologías.
2. ESTADO DE LA CUESTIÓN
Para realizar este análisis se definirán criterios de evaluación tanto teóricos como
prácticos que abarcan la mayor parte de las funcionalidades proporcionadas. Luego se
definirán valores para cada uno de los caracteres evaluados para culminar con una
comparación entre las distintas plataformas analizadas. Por último se realizará un
resumen de las plataformas analizadas indicando caracteres positivos, negativos y
deseables que se constituirán en la principal entrada para la definición del problema a
tratar.
El mercado actual presenta una gran variedad de plataformas de desarrollo para los
lenguajes existentes, como ejemplos se pueden nombrar:
z Java c Trails
c Struts
c JSF
c WebWork
c Tapestry
c Turbine
c Shale
z .NET
c .NET Framework
c Mono
z PHP
c Prado
c CakePHP
z Ruby
c Ruby on Rails
Experiencia
Características generales
z Son opensource.
En general las plataformas utilizan el patrón de diseño Model 2, basado en el patrón MVC
(Model-View-Controller) [Buschmann, Meunier, Rohnert, Sommerland & Stal, 1996].
Debido a esto se presentará una introducción al patrón Model 2.
Model 2
Si se es familiar con los patrones de diseño se debe haber oído en alguna ocasión sobre
el patrón MVC, este patrón tiene sus orígenes en Smaltalk, donde se utilizaba en la
realización de interfaces gráficas para aplicaciones “tradicionales” (no-Web).
El Modelo es responsable por los datos y las reglas del sistema. El Modelo coordina la
lógica de negocio, los datos y todas aquellas partes cruciales pero no visuales del
sistema. Tomando como ejemplo una planilla de cálculos, el Modelo son los números y
fórmulas que constituyen los datos.
MVC fue creado para poder manejar la interfaz gráfica de las aplicaciones Smalltalk. La
idea sin embargo no encaja en buena forma para el desarrollo de aplicaciones Web. No lo
era al menos hasta que el patrón fue extendido para ser conveniente para el desarrollo
Web.
La aparición de Model 2
En las aplicaciones Web el modelo de la interfaz de usuario está más desacoplado que en
los entornos de desarrollo tradicionales como son las aplicaciones de escritorio. Es por
eso que los diseñadores tomaron como base MVC y lo modificaron para ser aplicado al
nuevo paradigma de desarrollo. Este trabajo fue el que dio origen a “Model 2”, como una
segunda versión de MVC.
En las aplicaciones Model 2, los Java beans representan el modelo, estos pueden incluir
tanto Java beans, Enterprise Java beans, o Java beans que actúan como proxies de los
EJB. La vista es mostrada utilizando JSP y el controlador es un Servlet.
Figura 1: Model 2
El usuario invoca el controlador utilizando el browser. El servlet crea uno o más Java
beans que realizan el trabajo. El servlet agrega el/los beans a un JSP y redirige el control
al JSP. El JSP extrae los beans y muestra el resultado.
Usando frameworks
Características particulares
Struts
Struts está diseñado para ayudar a los desarrolladores a crear aplicaciones Web
utilizando una arquitectura MVC.
z Un servlet controlador encargado de dirigir los pedidos a las clases de tipo Action
El flujo de información básico de una aplicación que utiliza Struts se muestra en la Figura
2.
Struts.
Las acciones crean los objetos del modelo y realizan actividades propias del dominio
(ejecutar lógica de negocio, conectarse a la base de datos, o llamar a otros métodos).
Una vez que la acción realiza el trabajo, redirige el modelo a la vista, generalmente un
JSP. La vista extrae los datos del modelo y presenta los resultados al usuario.
Una de las fortalezas de Struts es que provee los mínimos componentes necesarios para
aplicar Model 2 a la construcción de aplicaciones Web.
JSF
JSF es una plataforma desarrollada a través del Java community Process por Sun
Microsystems. [WEB-6]
Con la contribución de un grupo de expertos, la API fue diseñada de forma tal de hacerla
extensible y mejorada a través de herramientas que hagan aún más fácil el desarrollo de
aplicaciones Web.
z Una librería de tags de JSP para poder utilizar los componentes de JSF en
páginas JSP.
El flujo de información básico de una aplicación que utiliza JSF se muestra en la Figura 3.
Diseñado para ser flexible, JSF se encarga de enriquecer los conceptos tradicionales
relacionados con la interfaz de usuario Web debido a que maneja los componentes
visuales como componentes encapsulados en clases que incluyen las funcionalidades
internas de los mismos (no la lógica de presentación al cliente). De esta forma los
componentes pueden ser visualizados en distintos dispositivos.
Teniendo a la facilidad de uso como su principal objetivo la arquitectura provista por JSF
define una separación de la lógica de la aplicación y la presentación pero sin dejar de lado
la facilidad para la comunicación entre la capa de presentación y el código de la
aplicación. Esto permite a cada uno de los miembros de un equipo de desarrollo
focalizarse en su parte del proceso de desarrollo.
WebWork
A diferencia de otras plataformas utiliza las APIs Web de Java en lugar de intentar
reemplazarlas.
WebWork introduce conceptos que son únicos y que lo distingue de otras plataformas,
como ser el PHMVC y la pila de valores (quien se encarga de proveer la información a la
vista).
WebWork fue construido por el proyecto Open Symphony (que incluye varios proyectos,
siendo WebWork uno de ellos).
WebWork implementa el patrón conocido como “Pull HMVC”, que significa “Pull
El resto de la arquitectura es MVC, lo que implica que WebWork sigue los lineamientos
general de Model 2 a excepción de la forma en que la información del modelo es puesta a
disposición de la vista.
Como en Struts, WebWork incluye un controlador central que crea objetos Action.
Tapestry
Tapestry es una plataforma de mayor tamaño que Struts. Está provista de componentes
gráficos así como también aquellos necesarios para manejar pool de objetos y manejo de
sesión. Debido a la naturaleza de la plataforma, orientada a componentes reutilizables
permite un alto grado de reutilización de componentes relacionados con necesidades
comunes en el desarrollo Web.
Para la presentación, Tapestry utiliza una alternativa a los lenguajes de scripting, como
ser JSP y Velocity. Provee, en cambio, una combinación con Java reflection, JavaBeans y
templates de HTML.
Una aplicación escrita con Tapestry comienza cuando el usuario accede utilizando un
browser apuntando al ApplicationServlet de Tapestry. El servlet actúa como un
controlador universal. Crea el Application Engine, que es el objeto de la plataforma
encargado de manejar la interacción del usuario con la aplicación. Una instancia del
engine es creada por cada usuario y actúa como un proxy para ese usuario. El engine lee
la especificación de la aplicación de un archivo de configuración en el que se definen las
páginas. Luego se lee la especificación de la página y el template de la página requerida
para determinar el contenido de la misma (sus componentes) y utiliza ésta información
La mayoría de los archivos de configuración son cacheados en memoria, de forma tal que
el proceso de lectura de archivos de configuración no sea costoso a nivel de recursos.
Análisis teórico
Para poder realizar una comparación a nivel teórico de las plataformas escogidas se
definirá un conjunto de características que se consideran deseables y que contribuyen a
solucionar los problemas planteados. [Ford, 2004] [McClanahan, 2005] [McClanahan,
2006] [WEB-5]
Criterio de evaluación
Grillas/Tablas
Bookmark
Validación
¿De qué forma es posible realizar validación del lado del cliente utilizando Javascript?
Testeabilidad
¿Es posible hacer test unitario de los controladores sin necesidad de iniciar un
contenedor?
Post y redirección
Internacionalización
Decoración de páginas
Herramientas
Marketing
Componentes reutilizables
Comunidad
Se valorizan la existencia de páginas oficiales, foros, wikis, etc. ¿Se pueden conseguir
respuestas a las preguntas de forma rápida?
Madurez de la tecnología
Se analiza:
z Frecuencia de releases.
Define si existe la posibilidad de trabajar con algún lenguaje de markup estático y/o
dinámico para definir las vistas. ¿Soporta JSP? ¿Qué otras alternativas permite?
Acceso a recursos
Navegación de páginas
¿De qué manera se define el flujo de páginas? y ¿de qué manera se pueden compartir
modelos entre páginas?
Wizards
¿De qué forma se pueden construir Wizards?, es decir, sucesión de páginas que tengan
un modelo en común. Utilizando wizards la modularización del código en grandes
aplicaciones se simplifica ya que manteniendo fijo el modelo de entrada y salida de un
wizard este puede modificarse libremente. A su vez la creación de los mismos permite la
reutilización de grandes porciones de código.
1-Struts
• Internacionalización
• Validación de entradas
• Maquetación
Struts tiene un vocabulario específico para definir cómo funcionan los términos; los más
importantes a definir son los siguientes:
• Actions: Posible acción a invocar. Son objetos que heredan de la clase Action
donde se escribe que es lo que se hará. Por ejemplo se puede decidir invocar
alguna regla de negocio y en base a su resultado mostrar la vista que corresponda.
• ActionMaping: mapea las URLS (estructura con la que se manejan los clientes
webs) a acciones (objetos). Es decir, se le da un nombre a cada clase acción de
manera que puedan ser invocadas desde el cliente como un string.
1. El cliente solicita una página que contiene datos a completar (no mostrado).
5. La acción recibe el formulario y con sus datos invoca a las reglas del negocio
(generalmente delegadas en otros objetos).
Por el lado del controlador existe un servlet que recibe todas las peticiones, por el lado de
la vista Struts entrega una serie de bibliotecas de TAGs para embeber en el HTML de
manera que sea más fácil acceder a los beans y generar las vistas. Estos tags se dividen
en 4 grupos:
Estas etiquetas permiten generar vistas conteniendo sólo tags y sin código Java. La
manera de relacionar los datos entre la aplicación java y la vista se realiza de la siguiente
forma:
En la vista, cada etiqueta que necesite tener un valor accesible desde la acción deberá
tener un nombre igual al del form asociado con la acción. De esta manera Struts realiza el
binding entre el valor del tag y el valor del atributo del formulario de manera automática.
Por ejemplo, si en el form HTML hay una entrada texto que se debe guardar en un bean
<html:text property="nombre">
Por otro lado, si desde la vista se desea acceder a valores (objetos, propiedades, etc.)
establecidos desde el action. Se puede utilizar los tags correspondientes para acceder a
los objetos. Es posible navegar los objetos mediante un lenguaje especial para acceder a
sus propiedades.
<table>
<logic:iterate id="unatienda" name="tiendas" scope="request"
type="com.empresa.Tienda">
<tr>
<td>
<bean:write name="unatienda" property="nombre" />
</td>
<td>
<bean:write name="unatienda"
property="responsable.nombre" />
</td>
</tr>
</logic:iterate>
</table>
En este caso, en el bean del formulario debe existir un método getTiendas que posea una
colección de objetos de la clase Tienda. La Tienda a su vez deberá tener un método
getResponsable que devuelva un objeto que tenga un método llamado getNombre. A
cada ítem de la colección se le hace referencia dentro del tag bean:write a través del
nombre una Tienda.
Internacionalización
...
app.titulo=Página Principal
form.Nombre=Nombre
form.Apellido=Apellido
boton.enviar=Enviar
....
<html:html>
<head>
<title>
<bean:message key="app.titulo" />
</title>
</head>
<body>
<html:form action="/unaaccion">
<html:message key="form.nombre" />:<html:text
property="nombre">
<html:message key="form.apellido" />:<html:text
property="apellido">
<html:submit>
<bean:message key="boton.enviar" />
</html:submit>
</html:form>
</body>
</html:html>
Luego, si se quiere localizar por ejemplo para idioma inglés sólo hace falta crear un nuevo
archivo recursos_En.properties copiando el contenido del original y reemplazando los
valores del lado derecho por los del idioma correspondiente.
Validación de entradas
Struts provee mecanismos de validación de las entradas ingresadas. Existen dos maneras
principales: Redefiniendo el método validate() de los ActionForms o a través de lo que
primero fue un plugin y luego se incorporó a la versión principal y que se denomina struts-
validator.
Esta parte del framework permite agregar validadores a los campos de los formularios que
se ejecutarán tanto del lado del cliente (mediante Javascript) como del lado del servidor
así como también definir las rutinas de validación más utilizadas. Todo esto se configura
<form-validation>
<global>
<validator name="validador1"
classname="clase.java.de.validacion" method="MetodoDeLaClase"
methodParams="java.lang.Object,com.un.Tipo"
msg="error.mensajes.nombre">
<javascript>[código javascript]</javascript>
</validator>
</global>
</form-validation>
<form-validation>
<formset>
<form name="FormInicio">
<field property="nombreusuario" depends="required">
<arg0 key="forms.nombreusuario" />
</field>
</form>
</formset>
</form-validation>
Maquetación
• A través de un xml
2-Tapestry
• Manejo de eventos
• Construcción de componentes
• Validación de entradas
• Internacionalización
Las vistas de Tapestry no son ni más ni menos que archivos en HTML estándar. No
existen las bibliotecas de tags ni código java. La única diferencia es la existencia de
algunos atributos extras en los elementos que aparecen.
Un atributo de los que aparece es el jwcid. Jwcid significa Java Web Component ID por lo
que el valor de ese atributo es ni más ni menos que el tipo de componente al que se está
refiriendo. Por ejemplo:
indica que el elemento html input hace referencia un componente TextField. Como ya se
definió anteriormente, una página generada con estos atributos se denomina template
Html. Estos templates, al renderizarse generan el html que es enviado al cliente.
Para vincular el código java con el html, Tapestry utiliza un lenguaje especial en los
templates HTML llamado OGNL que significa Object Graph Navigation Language y
permite expresar el acceso a un valor de algún objeto en forma de cadena de texto. A
partir de un objeto que sirve como punto de partida se puede navegar a través de sus
propiedades hasta llegar al elemento deseado. Por ejemplo, si deseo acceder al precio
del primer producto del carro de compras en que java lo haría como:
elCarro.getItemCarro[0].getProducto().getPrecio()
elCarro.itemCarro[0].producto.precio
HTML
<html>
<head>
<title>Ejemplo</title>
</head>
<body>
<form jwcid="@Form" listener="ognl:listeners.enviar">
<input type="text" jwcid="@TextField" value="ognl:valor" />
<input type="submit" jwcid="@Submit" value="Enviar" />
</form>
</body>
</html>
.Page
<?xml version="1.0"?>
<!DOCTYPE ...>
<page-specification class="Clase">
<property-specification name="valor" type="java.lang.String" />
</page-specification>
Clase.java
Es importante notar que tanto la clase como los métodos de acceso son abstractos esto
es porque Tapestry crea una instancia concreta heredando en tiempo de ejecución donde
le agrega métodos con implementación propia.
Manejo de eventos
Construcción de componentes
En Tapestry todos son componentes, incluyendo las páginas. Por lo tanto, al crear
páginas estamos creando nuevos componentes. La creación de componentes se realiza
de manera similar a la creación de páginas. Por lo general se requiere un template html,
un archivo de definición (xml) y un archivo con la implementación (java). Es posible crear
componentes que incluyan componentes y la facilidad con la que se pueden crear nuevos
componentes es casi la misma que para crear nuevas páginas.
Validación de entradas
Los componentes que reciben la entrada del usuario, permiten la validación a través de
dos parámetros: displayname y validators.
<label for="userName">Nombre:</label>
<input name="userName" id="userName" value="" size="30" />
<font color="red">
<label for="userName">Nombre:</label>
</font>
<input name="userName" id="userName" value="" size="30" />
<font color="red">**</font>
Resultando en:
Nombre: _____________ **
<page-specification>
...
<component id="inputPassword" type="TextField">
<binding name="validators"
value="validators:required,minLength=4" />
</component>
</page-specification>
Internacionalización
Para indicar una referencia a una clave dentro del HTML se utiliza la palabra message
Esta segunda opción es más transparente para los diseñadores y no requiere del prefijo
message.
3-JSF
• Manejo de eventos
• Internacionalización
• Validación de entradas
• Construcción de componentes
<navigation-rule>
<from-view-id>/buscador.jsp</from-view-id>
<navigation-case>
<from-outcome>exito</from-outcome>
<to-view-id>/resultado.jsp</to-view-id>
</navigation-case>
</navigation-rule>
El tag from-view-id puede contener comodines como por ejemplo /formulario-*.jsp. Dentro
de las reglas de navegación pueden haber de cero a muchos casos de navegación. El
caso de navegación se selecciona en función del valor utilizado para indicar la acción a
realizar (si es que hay alguna) y del valor de retorno de las llamadas al método invoke()
de dicha acción que es expresado en el tag from-outcome. Por último, se selecciona la
vista a mostrar indicada en el elemento to-view-id del caso.
de que se ejecute la acción buscar del bean UnBean. La diferencia es que el primer
ejemplo también requiere como condición de activación que el resultado de la ejecución
retorne “exito”.
<navigation-rule>
<from-view-id>/buscador.jsp</from-view-id>
<navigation-case>
<from-action>#{UnBean.buscar}</from-action>
<from-outcome>exito</from-outcome>
<to-view-id>/resultado.jsp</to-view-id>
</navigation-case>
<navigation-case>
<from-action>#{UnBean.buscar}</from-action>
<to-view-id>/busqueda-error.jsp</to-view-id>
</navigation-case>
</navigation-rule>
Binding de Valores:
Todos los componentes de interfaz permiten enlazar sus atributos y propiedades con
valores de alguna propiedad de algún bean. Para enlazar los valores con los atributos se
debe encerrar entre #{} el campo que se desea enlazar. Un ejemplo puede ser el
siguiente.
<h:outputText value="#{usuario.nombre}"/>
Usuario es un bean que tiene una propiedad nombre cuyo valor aparecerá en la pantalla
cuando se renderice el campo de texto.
Si bien se mostró un ejemplo del tipo #{objeto.propiedad}, también se permiten otro tipo
Para poder enlazar correctamente los valores de un componente de interfaz con los de un
bean, las propiedades que se enlazan tienen que ser de tipos compatibles o debe haber
un convertidor (Converter) asociado. JSF provee un amplio set de convertidores pero
también es posible definir nuevos. Para indicar el convertidor a utilizar, se lo puede hacer
así:
<h:outputText value="#{unBean.fecha}">
<f:convertDateTime type="date" dateStyle="medium" />
</h:outputText>
Binding de Métodos
Las expresiones para enlazar métodos son una variante de la anterior y permiten la
ejecución de un método particular enviando parámetros y recibiendo, si es que existe, la
respuesta. La cantidad de parámetros y la respuesta están determinadas por el tipo de
método que se espera. Por ejemplo, para enlazar el atributo action con un método, se
espera que se lo invoque sin parámetros y que retorne una cadena de texto. Para enlazar
un método con el atributo ActionListener, se espera como parámetro un ActionEvent y
nada como respuesta. Otros tipos de métodos se necesitan para los atributos validator y
valueChangeListener. La sintaxis para enlazar métodos es similar a la utilizada para
enlazar valores.
Binding de Componentes
Manejo de Eventos
a dichos eventos mediante listeners de manera similar al modelo utilizado en, por ejemplo,
Swing. Así, una subclase de UIComponent puede informar de los cambios de estado que
considera significativos avisándole a todos los listeners que hayan registrado su interés
por los eventos.
Todos los eventos generados desde los componentes de la interfaz son subclases de
FacesEvent. Las dos subclases estándares que derivan de FacesEvent son ActionEvent y
ValueChangeEvent. ActionEvent generalmente se utiliza cuando se refleja el uso de un
control, como por ejemplo, el presionar un botón. ValueChangeEvent se utiliza cuando se
quiere reflejar el cambio de algún valor de importancia en el componente.
Del otro lado está la interfaz FacesListener que define los métodos básicos para poder
escuchar eventos. ActionListener y ValueChangeListener son las implementaciones
correspondientes para los eventos comentados anteriormente.
Los eventos se encolan a medida que van apareciendo. El manejo de eventos ocurre al
finalizar varias de las etapas del ciclo de vida de la petición. Un evento debe indicar en
qué etapa quiere ser entregado informándolo a través del método getPhaseId(). Es
posible indicarle una fase en particular o, simplemente, que lo entregue al finalizar la fase
en la que fue encolado.
Para registrar los listeners, los componentes deben tener métodos para agregarlos y
quitarlos. Estos métodos deben seguir una convención de nombres la cual excede a esta
publicación.
Mientras que se ejecuta una fase, se pueden encolar eventos invocando al método
queueEvent() de UIComponent. Estos eventos se procesaran una vez terminada la fase.
Internacionalización
La internacionalización de JSF está construida sobre la base del soporte que ya brindaba
JSF maneja el concepto de Locale (configuración local) activo. Este se utiliza cuando se
accede a los recursos, cuando se utilizan los conversores, etc. Los posibles Locales que
tendrá la aplicación se definen en el archivo de configuración.
<application>
<locale-config>
<default-locale>es</default-locale>
<supported-locale>en</supported-locale>
<supported-locale>fr</supported-locale>
</locale-config>
</application>
Para escribir texto internacionalizado en las vistas sólo es necesario informar cuál es el
recurso (ResourceBoundle) del que se leerán los datos
y luego utilizar las claves precedidas por el nombre que se le dio al recurso al cargarlo
JSF permite localizar los mensajes internos del framework. Para esto, cada
implementación posee un ResourceBoundle llamado javax.faces.Messages que contiene
todas las claves de los mensajes estándar.
Validación de entradas
del usuario se le pueden registrar 0 o más validadores. También es posible llamar a los
validadores en cualquier momento a través del validate() del componente.
JSF incluye varios validadores estándar pero también permite crear validadores nuevos
implementando una interfaz y definiendo los atributos que se utilizarán para configurarlo.
<h:form id=”fromPersona”>
<h:inputText id=”nombrePersona” value=”persona.nombre” />
<h:message for=”nombrePersona”>
<h:commandButtonvalue ="#{ msg.aceptar }" action="#{UnBean.mostrar}"
/>
</h:form>
// el
// mensaje de error según el locale del
// cliente
ResourceBundle bundle = ResourceBundle.getBundle("err.mensajes",
context.getViewRoot().getLocale());
String msg = bundle.getString("error.persona_novalida");
// Agrego el mensaje que será mostrado por
// el tag <h:messages>
context.addMessage (“nombrePersona”, new FacesMessage(msg));
return “error”;
}
}
Construcción de Componentes
JSF permite la creación de componentes propios con o sin render asociado. Sin embargo,
la creación no es sencilla y se necesita crear varios archivos dependiendo del tipo de
componente que se desea crear.
Evaluación de características
Símbolo Descripción
- No cumple
+ Cumple
Struts No provee por defecto un componente para grillas o tablas. Se pueden escribir -
librerías de tags con una complejidad media. Un ejemplo sencillo es el Display
Tag.
WebWork No provee por defecto un componente para grillas o tablas. Se pueden escribir -
librerías de tags con una complejidad media. Un ejemplo sencillo es el Display
Tag.
Tapestry Existe un componente grilla que esta incluido en la plataforma. Este permite +
ordenamiento y paginación por defecto. Este componente es contrib:Table.
Maneja un modelo de objetos tomando todos las propiedades del mismo por
defecto para cada una de las columnas. Este comportamiento puede ser
modificado.
Struts No posee soporte por defecto, hay que implementarlo de forma personalizada -
o utilizar tag libraries que soporten AJAX.
WebWork No posee soporte por defecto, hay que implementarlo de forma personalizada -
o utilizar tag libraries que soporten AJAX.
Struts Posee namespaces por lo que se hace sencillo guardar la URL de una +
aplicación.
JSF Realiza POST para toda acción de forma tal que las URL no son -
consideradas.
WebWork Posee namespaces por lo que se hace sencillo guardar la URL de una +
aplicación.
Tapestry Utiliza URL pero las mismas no son del todo llamativas y fáciles de entender +
WebWork Utiliza expresiones OGNL lo cual es increíblemente poderoso del lado del +
cliente.
Tapestry Posee una robusta validación por defecto sin necesidad de personalización +
Tapestry En principio se dificulta el testing debido a que las páginas de Tapestry son -
abstractas.
Struts Posee una integración directa a través de un plugin para agilizar el manejo de +
actions de struts a través de beans de Spring.
JSF No provee una forma de integración por defecto pero existen algunas -
soluciones que permiten esto.
WebWork Provee soporte por defecto para Spring. Se puede utilizar Spring como IoC. +
Tapestry Soporta la inyeccion de beans como servicios y también dentro de las páginas +
de Tapestry. también permite la inyeccion dentro de los componentes
personalizados de Tapestry.
Tapestry Invoca un archivo distinto por cada página. Incluye además una forma muy +
simple de invocar los mensajes internacionalizados (<span
key=”usuario.nombre”>
Struts Se puede utilizar junto con Tiles, pero requiere configuración en cada página. +
JSF Se puede utilizar junto con Tiles, pero requiere configuración en cada página. +
WebWork Se puede utilizar junto con SiteMesh, el cual es de más sencilla instalación y +
uso.
JSF Posee una gran variedad producto del soporte que posee por parte de Sun +
Microsystems debido a que es el “framework” oficial de esta compañía.
WebWork Existe EclipseWork que provee soporte para WebWork sobre el entorno +
Eclipse.
Tapestry Existe Spindle que provee soporte para Tapestry sobre el entorno Eclipse. +
14
12
10
8
WebWork
Struts
6 Tapestry
JSF
4
0
Cantidad
WebWork Esta ganando mercado pero se requiere en muy pocas ofertas laborales. -
2000
1500
WebWork
1000 Struts
Tapestry
JSF
500
0
2004 2005 2006
150
112.5
WebWork
75 Tapestry
JSF
37.5
0
2004 2005 2006
800
640
480
WebWork
Struts
Tapestry
320
JSF
160
0
Cantidad
Struts Se pueden escribir librerías de tags, pero utilizan html, y no son componentes -
extensibles y capaces de conservar estado.
WebWork Se pueden escribir librerías de tags, pero utilizan html, y no son componentes -
extensibles y capaces de conservar estado.
Struts Fue en el pasado la plataforma por defecto de las aplicaciones Web, esto está +
cambiando pero a pesar de esto la comunidad creada es suficientemente
grande y existe abundante bibliografía.
WebWork De las plataformas analizadas es la menos seguida, situación que cambió con -
la versión 2.0 ya que se “unió” con Struts creando una única plataforma.
Tapestry Posee una comunidad muy grande, y es auspiciada por Apache lo que provee +
un sinnúmero de recursos disponibles. A pesar de esto, el desarrollo es
monopolizado por su creador quien introduce cambios mayores entre
versiones sin respetar compatibilidad “hacia atrás”.
WebWork
Mensajes por mes (2006) Struts
Tapestry
JSF
30
22.5
WebWork
15 Struts
Tapestry
JSF
7.5
0
2007
Struts Posee un completo soporte para JSP incluyendo tags propios. Permite la -
utilización de Velocity para el manejo de templates. El manejo del layout
puede hacerse con Tiles
JSF Soporta JSP. además posee una forma de extender la API utilizando +
ViewHandler a través del cual se pueden utilizar distintas alternativas.
El manejo del layout se puede hacer con Tiles, en el layout se acomodan los
bastos componentes que integran la plataforma.
WebWork Posee un completo soporte para JSP y Velocity. El manejo de layout puede -
hacerse con SiteMesh.
Tapestry Utiliza HTML plano incluyendo tags con el atributo “jwcid” a través del cual se +
linkea la vista con los componentes.
Struts Utiliza XML para la configuración del mapeo de requests URL a clases Action. -
También tienen asociadas un bean para mantener el estado de la vista.
WebWork Utiliza las virtudes de XWork para realizar el mapeo de requests a Actions. -
JSF Utiliza Manager Beans. A su vez permite la integración con otros frameworks +
de IoC utilizando APIs de extensibilidad.
Tapestry Permite el uso de Spring e HiveMind. El ultimo es utilizado por el core mismo. +
JSF Cada Action retorna un valor que es mapeado a la próxima vista a través de -
un id por el NavigationHandler.
WebWork Cada Action retorna un String como resultado, que esta mapeado a una vista. +
RequestDispatcher.forward(), etc.
Tapestry Los Listeners pueden retornar, tanto void (se quedan en la misma página), +
String (URL) o una instancia de IPage que representa una nueva página a ser
renderizada.
Tapestry El estado esta en propiedades que poseen los componentes con los que se +
construyen las páginas.
o Grillas/tablas
El Problema
• Navegación de páginas
• Wizards
• Programar en el “molde”
• Adaptación a cambios en UI
Navegación de páginas: debido a que las aplicaciones enterprise poseen una gran
cantidad de datos, los mismos se presentan en varias páginas relacionadas entre sí; es
por esto que la navegación entre páginas, con el correspondiente traspaso de información
entre las mismas, debe ser parte del framework.
Necesidad de aprendizaje, más allá del utilizado para construir la aplicación, de lenguajes
adicionales (HTML, Javascript, CSS) que pertenecen al basamento del desarrollo de
aplicaciones Web: para contribuir al desarrollo enterprise es necesario que los
desarrolladores se focalicen en la lógica de negocio sin preocuparse por la presentación
(siendo esto tarea del diseñador gráfico, o en caso de ser necesario de desarrolladores
avocados específicamente a UI). Para poder realizar esto, la presentación debe estar
suficientemente desacoplada de la lógica.
Wizards: los wizards son clave tanto para la reutilización de código, no solo componentes
sino también conjuntos de páginas, como también por ser requeridos en aplicaciones
enterprise. El hecho de poder convertir un conjunto de páginas en un componente
permitiría la reutilización de interfaces de usuario y lógica de negocio.
4. SOLUCIÓN PROPUESTA
La Solución
Los casos de uso a su vez son invocados de la misma forma en que se envía un
mensaje a un objeto, teniendo de esta forma un modelo de entrada y uno de salida.
• Páginas: representan la mínima unidad que compone un caso de uso. Al igual que
los casos de uso las páginas presentan un modelo de entrada y uno de salida.
Arquitectura
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
configuration
persistence
predicates
messages
constants
closures
models
Se implementan los modelos que son utilizados por los componentes provistos por el
reports
Provee una abstracción para reportes realizados con JasperReports así como también
para la exportación de los reportes a formatos varios (PDF, HTML, XLS).
context
security
writers
Implementación de writers utilizados para generar código HTML a ser utilizado por los
componentes provistos y también aquellos implementados por los usuarios del mismo.
utils
Clases utilitarias varias, incluye soporte para fechas, cadenas de caracteres, colecciones
y renderización.
test
bo
Define la clase base para ser utilizada por los objetos de negocio que se pretendan
manejar en el framework para aprovechar la integración con Hibernate y Spring.
web
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
Componentes visuales
Introducción
button, group, etc). A su vez se incluyen componentes no visuales que son contenedores,
en general son layouts que determinan como se distribuyen los componentes en la
pantalla.
Pages
Las páginas son consideradas cajas negras por quien las invoca, es decir, se las invoca
con un modelo (pudiendo ser vacío) y estas retornan un modelo en caso satisfactorio y
otro modelo en caso de error.
Un modelo es una clase Java simple (POJO) que al ser recibido por una página puede ser
utilizado como modelo de la página de forma directa o también ser “decorado”. En ambos
casos cada página necesita de un modelo para poder funcionar.
El modelo de la página es una clase que cumple dos funciones básicas: contener el
estado de la página, siendo de este modelo leídos los valores de los controles, y
almacenados los mismos y también contener la lógica de negocio necesaria por ejemplo
para validar los datos ingresados por el usuario.
Veamos un ejemplo para entender cómo se invoca una página y se recibe el modelo de la
misma:
Esta implementación básicamente retorna un modelo nuevo para que los controles tomen
de él los datos y los actualicen en él.
Las páginas a su vez pueden implementar o enviar al modelo los listeners, encargados de
procesar eventos de los controles, como puede ser el evento click de un botón. En
cualquiera de los dos casos los listeners son métodos invocados ante un evento. Como
ejemplo veamos el siguiente caso donde un botón invoca un listener en el servidor y este
actualiza una etiqueta:
QMessageLabel lblText;
QuickTime™ and a
TIFF (Uncompressed) decompressor
QuickTime™ and a
TIFF (Uncompressed) decompressor are needed to see this picture.
are needed to see this picture.
Binding
Como se ha visto anteriormente toda página posee un modelo de donde se obtienen los
datos y donde está contenida la lógica del negocio.
Para acceder a los valores del modelo se utiliza el lenguaje OGNL (Object Graph
Navigation Language) con el que se acceden las propiedades de los objetos navegando
en el grafo generado utilizando el operador “.”. Por ejemplo: clásicamente si se posee la
clase Usuario y esta a su vez contiene una instancia de la clase Dirección que contiene
El acceso a través de OGNL se realiza de la siguiente manera por ejemplo para acceder
al campo codigoPostal del ejemplo anterior: usuario.direccion.codigoPostal, esto invocará
getUsuario().getDireccion().getCodigoPostal().
Layouts
Se reciben los controles a renderizar y un writer utilizado para escribir los tags de HTML.
Por defecto se presenta un Layout que ubica los controles en dos zonas: una general
(Top zone) y una para acciones (Action Zone):
Como es de esperar en la zona general se ubican todos los controles a excepción de las
acciones y en la inferior solamente las acciones.
De esta forma los controles, a medida que son agregados se van ubicando uno al lado del
otro de izquierda a derecha hasta alcanzar el límite por fila que es configurable.
A su vez, el layout por defecto considera a los controles de diferentes anchos según su
tipo, por ejemplo: los controles con etiqueta ocupan 2 espacios (uno para la etiqueta y uno
para el control). Un ejemplo de cómo funciona este layout es el siguiente:
El código es:
Siguiendo con la misma idea se provee un layout de tipo File (es decir que se carga desde
un archivo). Este layout permite trabajar con diseñadores gráficos de manera totalmente
independiente. La idea es que el layout es un archivo HTML clásico y los controles se
agregan al layout utilizando placeholders con el formato ${NOMBRE_DEL_CONTROL}.
Como ejemplo, veamos esta página donde se puede ingresar un texto y al presionar el
botón se presenta el texto ingresado:
El código es:
lblBuscado.setVisible(QDummyPredicate.FALSE);
QCF.action(form, "btnBuscar", "onBuscar");
}
public String getBusqueda() {
return "";
}
public void setBusqueda(String valor) {
busqueda = valor;
}
public void onBuscar() {
lblBuscado.setKey("El texto buscado es: " + busqueda);
lblBuscado.setVisible(QDummyPredicate.TRUE);
}
Luego:
El funcionamiento es el mismo:
<html>
<body style="text-align: center;">
<img alt="Google" src="/img/google-logo.gif" height="110" width="276"><br><br>
<form action="/search" name="f">
<table cellpadding="0" cellspacing="0" align="center">
<tbody>
<tr valign="top">
<td width="25%"> </td>
<td align="center" nowrap="nowrap">
<input name="hl" value="en" type="hidden">
${txtBusqueda}<br>
${btnBuscar}
<input name="btnI" value="I'm Feeling Lucky" disabled type="submit">
</td>
<td nowrap="nowrap" width="25%"><font size="-2">
<a href="/advanced_search?hl=en">Advanced Search</a><br>
<a href="/preferences?hl=en">Preferences</a><br>
<a href="/language_tools?hl=en">Language
Tools</a></font></td>
</tr>
<tr><td colspan="3" align="center">${lblBuscado}</td></tr>
</tbody></table></form><br><br>
<font size="-1"><a href="/intl/en/ads/">Advertising Programs</a>
- <a href="/services/">Business Solutions</a>
- <a href="/intl/en/about.html">About Google</a>
- <b><a href="http://www.google.com.ar/">Go to Google
Argentina</a></b></font><p>
<font size="-2">©2007 Google</font>
</body>
</html>
Más allá de los layouts provistos por defecto, se pueden implementar layouts propios,
simplemente heredando de QAbstractLayout e implementando el siguiente método:
Donde se reciben los elementos y un writer, los elementos son todos los componentes y
el writer es utilizado para escribir tags HTML, combinando estos dos elementos se pueden
generar todo tipo de layouts.
Containers
Todos los controles con contenedores, es decir que pueden contener otros controles, esto
se logró aplicando el patrón Composite. Más allá de esto existen controles que son
contenedores explícitos, como ser: QGroup, QFieldSet o QFormPanel. Los primeros dos
son contenedores visuales mientras que el último no.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
Este diseño permite que se puedan combinar los controles de casi cualquier manera para
generar nuevos componentes reutilizables.
Validation scope
Como ejemplo vemos un caso donde en una página se carga un nombre y una dirección,
pero para la carga de la dirección se utiliza otra página:
Vemos el código:
QCF.textField(group1, "txtNombre",
"nombre").addValidator(QRequiredValidator.getInstance());
QGroup group2 = QCF.group(group1, "grp2");
QCF.textField(group2, "txtDireccion",
"direccion").setEnabled(QDummyPredicate.FALSE);
QCF.action(group2, "btnDireccion",
"onDireccion").setValidationScope(group1);
}
Group
Componente Código
QGroup QCF.group(form,
"grp”);
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime and a
QGroup TIFF (Uncompressed) decompressor
are needed to see this picture.
Fieldset
Componente Código
QFieldSet QCF.fieldSet(form,
"fds”);
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
Actions
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
Componente Código
QuickTime™ and a QCF.action(form, "btnEnabled", "onEnabled");
QAction TIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and a QCF.action(form, "btnDisabled",
QAction TIFF (Uncompressed) decompressor
are needed to see this picture. "onDisabled").setEnabled(QDummyPredicate.FALSE);
Inputs
Los componentes input son aquellos que son utilizados para capturar datos del usuario y
luego ser transmitidos al modelo ubicado en el servidor. Al momento de construir el
componente se especifica a que atributo del modelo corresponden los datos ingresados
por el usuario.
Es destacable que los datos del modelo son actualizados en los dos sentidos, es decir, al
Componente Código
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QComboSelector QCF.comboSelector(form,
"cmbCountry", "country",
"countries", "");
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QComboSelector QCF.comboSelector(form,
"cmbCountry", "country",
"countries", "").
setHasNullElement(false);
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QRadioSelector QCF.radioSelector(form,
"cmbCountry", "country",
"countries", "");
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QRadioSelector QCF.radioSelector(form,
"cmbCountry", "country",
"countries",
QuickTime™ and a "").setHasNullElement(false);
TIFF (Uncompressed) decompressor
are needed to see this picture.
Palette
Componente Código
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
Menú
Componente Código
Table
Como todos los controles el control Table está vinculado con un modelo. En este caso el
modelo es una lista de objetos.
Para presentar las columnas de la tabla se vincula cada columna a un atributo de la clase
de objetos contenidos en la colección. Por ejemplo, en la siguiente tabla se utiliza la clase
Pais que contiene dos propiedades: nombre y población.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
Además de columnas con datos el componente Table presenta opciones para agregado
de acciones por fila y generales como se ve a continuación:
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
En este caso se agregaron dos acciones, una acción de grilla (Nuevo) y una acción por
fila (Editar). El código necesario para realizar lo anteriormente explicado es:
Con respecto a las filas, la renderización de las mismas puede ser modificada para
soportar no solo la presentación de datos sino que también la edición de los mismos,
como se ve a continuación donde el campo Nombre es editable:
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
grd.addTableAction("btnNew","onNew");
Otra funcionalidad destacada del componente Table es la selección de filas que permite
mostrar una grilla seleccionable:
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
El código es:
Funcionamiento
Ciclo de vida
Ahora veamos un ejemplo que muestra la renderización de una página incluyendo sus componentes:
Patrones utilizados
Front Controller.
Delega en el engine los pedidos, tanto GET como POST a la vez que inicializa el contexto
de usuario almacenado en el request.
Diagrama:
MVC
Diagrama:
Template View
Descripción: El problema que presentan las páginas Web dinámicas, aquellas que toman
resultados de queries a base de datos y luego se agregan al HTML, es que estas páginas
se ven distintas con cada resultado.
La mejor manera de realizar este trabajo es creando páginas Web estáticas pero
colocando marcadores o placeholders que pueden ser procesados para colocar en esa
posición la información dinámica. Como la parte estática actúa como un template para
una respuesta en particular, se conoce a este patrón como Template View.
De esta forma, se puede trabajar en simultáneo y sin interferir con el trabajo realizado por
el diseñador gráfico.
Diagrama:
Composite
Tipo: estructural
Funcionamiento: Al utilizar Composite, todos los objetos presentan una interfaz común a
los clientes para que estos traten de igual forma a los objetos simples como a la
composición de los mismos.
permitiendo agregar controles a todo control y poder obtener los controles contenidos. De
esta forma se pueden generar componentes visuales tan complejos como se pretenda. A
su vez los layouts y containers implementan QControl (por ende Composite) y esto
presenta una interfaz común que simplifica la renderización siguiendo diferentes
algoritmos.
Diagrama:
Tipo: estructural
Una forma de solucionar esto es mediante la herencia, pero esto hace que si hereda una
clase de una que tiene borde, todas las heredadas tienen borde; esto es inflexible debido
a que es un agregado estático.
Una solución flexible sería incluir el componente al que se desea agregar un border en
otro que le provea el borde. Éste componente que “bordea”/”decora” al primero es
conocido como Decorator.
forma tal de que su presencia sea transparente al cliente que lo usa. El decorador
reenvía las llamadas al componente interno pudiendo realizar acciones adicionales, como
ser agregar un borde antes de reenviar las llamadas.
El hecho de que el decorador sea transparente permite que el anidamiento sea recursivo
y sin límites.
Diagrama:
Command
Tipo: comportamiento
Funcionamiento: Se implementa mediante una clase Command, que declara una interfaz
para ejecutar operaciones. La forma más simple de la interfaz incluye la operación
execute. Las implementaciones concretas especifican un par receptor-acción
almacenando una instancia del receptor e implementando execute invocando la acción en
el receptor. Es el receptor quien posee la información necesaria para resolver la acción.
De ésta forma cuando una página invoca a otra o a un caso de uso, puede implementar
una QFinalizeAction que realice alguna acción cuando la página/caso de uso invocado
retorna.
Diagrama:
Builder
Tipo: creacional
Funcionamiento: Se define una clase que se encarga de construir los objetos complejos.
Domain Model
Query Object
Funcionamiento: El objeto Query Object agrega criterios para realizar las sentencias
SQL a partir de clases y atributos de las mismas.
Con estos criterios genera la sentencia SQL necesaria para obtener los datos deseados.
Estos criterios los asigna al Mapper que obtiene dependiendo de la clase, y con la
información de la clase de los Mappers y los criterios se genera la sentencia SQL final con
la cual se consulta la base de datos. De esta manera, se independiza del lenguaje de
consulta y de la forma que se persisten los datos.
A su vez las criterias se pueden encadenar con operadores lógicos: AND y OR, y también
negar con NOT.
Por último, el query, se corre retornando los resultados en base a los criterias aplicados.
Repository
Un Repository media entre el dominio y las capas de mapeo de datos, actuando como si
se tratase de una colección en memoria de objetos.
Casos de aplicación
Luego se definirá una aplicación enterprise partiendo de sus requerimientos, casos de uso
y diseño. Con la aplicación definida se procederá a implementar la misma con la
plataforma presentada como solución al problema que da origen a éste trabajo.
“BugMetric”
Descripción
BugMetric es una aplicación utilizada para obtener métricas basadas en fallas o defectos
encontrados en proyectos informáticos. BugMetric permite a través de sus múltiples
reportes la toma de decisiones necesarias para corregir posibles desvíos o tendencias
incorrectas de un proyecto.
Requerimientos
El siguiente escenario describe el flujo de una orden a través del sistema. La secuencia
de eventos es la que sigue:
1. Se crea un proyecto
Casos de uso
Arquitectura
Una visión de alto nivel de la arquitectura de la aplicación puede verse en la Figura 46.
Este diagrama muestra los principales componentes de la aplicación y sus actores. Posee
una arquitectura estándar de 3 capas, a saber: presentación Web, negocio y acceso a la
base de datos.
Como es de esperar, la aplicación almacena sus datos en una base de datos relacional.
z El usuario de control de calidad selecciona su nombre para indicar que el fue quien
reporto.
Flujo de páginas
Conclusiones
Descripción
Conclusiones
Una última utilidad que resultó muy ventajosa fue la manera en que se organizan los
casos de uso, ya que se pueden definir las pantallas que involucran a los mismos; lo que
no sólo ayuda a acelerar el desarrollo de éstos sino que también queda muy en claro a la
hora de hacer modificaciones o extensiones de los casos de uso existentes.
6.1 Conclusiones
Navegación de páginas
Wizards
Por último el hecho de que se generen wizards utilizando casos de uso permite la re-
utilización de un wizard en distintas partes de una aplicación.
La solución permite que nuevos recursos se puedan adaptar a un equipo debido a que el
conocimiento de base necesario es Java, y a partir de allí el recurso puede comenzar
trabajando en la lógica de negocio (la cual no posee ninguna restricción de la plataforma)
y luego moverse a trabajar con la interfaz de usuario, pero manteniendo el lenguaje de
Programar en el “molde”
Esto permite que se trabaje con prototipos extensibles y no con prototipos descartables.
Adaptación a cambios en UI
Debido a que el código de la UI es realizado 100% en Java, esto permite aprovechar las
virtudes de un lenguaje orientado a objetos, a su vez, permite refactorizar el código,
generalizarlo y reutilizarlo.
Por otro lado, en caso de utilizar un layout con archivos y placeholders, esto permite que
la UI cambie sin impactar en la lógica de negocio.
Incompatibilidad de navegadores
Cada proveedor implementa los estándares de forma distinta, lo que dificulta aún más la
situación.
La utilización de otros trabajos da validez a los mismos, a la vez que el hecho de ser
utilizado el modelo obtenido demuestra que se obtuvo no sólo un resultado experimental.
La integración se realizó en dos sentidos: por un lado parte de implementación del modelo
solución utiliza el trabajo realizado por los Ingenieros Carlos Curotto y Pablo Díaz:
“Persistence Framework” como una alternativa al framework Hibernate para realizar la
persistencia de objetos. Por otro lado desde las primeras versiones de la solución
propuesta, los futuros Ingenieros Diego de Paz Sierra y Sebastián Marucci han utilizado a
uthopy como plataforma de desarrollo obteniéndose resultados satisfactorios.
Si bien se provee una solución completa a los problemas analizados, la misma puede ser
llevada a un nivel superior.
En primer lugar debe quedar en claro que la solución es un modelo que define
lineamientos que se deben seguir para solucionar los problemas clásicos en el desarrollo
• Desacoplar ciertas partes del código de otras plataformas: tanto Spring como
Hibernate son una base importante de la solución y es recomendable desacoplar la
solución para poder abarcar más tecnologías.
Más allá de los puntos para revisar, existen cambios que mejorarían las prestaciones:
• Soporte mejorado para AJAX: si bien la solución soporta AJAX sería deseable un
soporte más integrado con la plataforma permitiendo que todos los controles
puedan comunicarse con el servidor tanto de forma convencional como de modo
asincrónico utilizando AJAX.
contribuiría a mejorar la calidad del mismo así como también se obtendría una
respuesta de aceptación.
7. BIBLIOGRAFÍA
[Gamma et al, 1995] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides,
Design Patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.
[Walls, 2005] Craig Walls, Ryan Breidenbach, Spring in Action, Manning, 2005
[Crane, 2006] Dave Grane, Eric Pascarello, Ajax in Action, Manning, 2006
[Forman, 2005] Ira Forman, Nate Forman, Java Reflection in Action, Manning, 2005
[Bauer, 2005] Christian Bauer, Gaving King, Hibernate in Action, Manning, 2005
[Sierra, 2002] Katht Sierra, Bert Bates, Sun Certified Programmer & Developer for Java 2,
Osborne, 2002
[Tong, 2005] Ka Iok Tong, Enjoy Web Development with Tapestry, 2005
[McClanahan, 2002] Ted Husted, Cedric Dumoulin, George Franciscus, David Winterfeldt,
Craig R. McClanahan, Manning, 2002
[Brose, 2005] Ed Roman, Rima Patel Sriganesh, Gerald Brose, Mastering Enterprise
JavaBeans, Wiley Publishing, 2005
[Ford, 2004] Neal Ford, Art of Java Web Development, Manning, 2004.
[Raible, 2006] Matt Raible, Java Web Framework Sweet Spots, 2006.
[Buschmann, Meunier, Rohnert, Sommerland & Stal, 1996] Frank Buschmann, Regine
Meunier, Hans Rohnert, Peter Sommerland y Michael Stal, Pattern Oriented Software
Architecture, 1996.
[Curotto & Diaz, 2007] Carlos Curotto y Pablo Diaz, Trabajo Profesional Persistence
Framework, 2007.
[WEB-1] http://tomcat.apache.org/
[WEB-2] http://struts.apache.org/
[WEB-3] http://jakarta.apache.org/tapestry/index.html
[WEB-4] http://jakarta.apache.org/commons/index.html
[WEB-5] http://static.raibledesigns.com/repository/presentations/
[WEB-6] http://java.sun.com/javaee/javaserverfaces/
[WEB-7] http://www.opensymphony.com/webwork/
8. ANEXOS
En esta sección se construyó utilizando un cuestionario común que fue realizado a los
autores: [Raible, 2006]
3. ¿De los otros frameworks analizados, ha probado alguno de ellos? ¿En caso
afirmativo, cuáles, y qué le ha gustado de cada no? ¿Qué no le gusto?
1-JSF
¿Cuál es el contexto de aplicación ideal del framework y para qué tipos de proyectos es
altamente recomendado pensar en su framework como medio para resolver el problema
planteado?
JSF no requiere código especial en las Actions, no exige dependencias en el modelo, solo
la Vista. Esta simpleza hace que el desarrollo sea altamente ágil y promueve la
reutilización de componentes entre aplicaciones. Estas facilidades permiten incluso a
desarrolladores novatos a trabajar sin requerir coordinar vistas con actions, pasaje de
parámetros, manejo de estado y renderización.
De los otros frameworks analizados, ¿ha probado alguno de ellos? En caso afirmativo,
¿cuáles, y qué le ha gustado de cada no? ¿Qué no le gusto?
Struts
WebWork
Puntos en contra: Como todos los otros frameworks basados en acciones, UIs complejas
pueden resultar difíciles de mantener sin utilizar grandes cantidades de código.
Tapestry
No es una pregunta que aplique a JSF. JSF es una especificación y está basado en lo
que ha sido agregado por la comunidad de desarrolladores.
Relacionado con AJAX, se está planificando una extensión para JSF 1.2 denominada
Avatar, que permitirá cualquier parte de JSF a ser usada en una aplicación AJAX.
La próxima revisión de JSF (2.0) incluirá soporte para “Partial Faces Request” (AJAX).
También existirá una mayor utilización de annotations para simplificar el desarrollo de
nuevos componentes (especificación).
Existen demasiados tutoriales y libros acerca de JSF que demuestran que es muy sencillo
encarar aplicaciones simples con JSF pero no hacen hincapié en las virtudes que JSF
presenta en cuanto a escalabilidad e interacción de Uis que hubieran sido imposibles de
manejar con otros frameworks sin grandes cantidades de código.
A su vez, JSF puede manejar requests realizados a través del método GET de forma tan
simple como los otros frameworks. Debido a contenedor de Ioc se pueden realizar las
mismas cosas que se hacen con WebWork – binding entre componentes de la vista y un
bean. Un ejemplo es el enlace entre páginas en las que se pasan ids, se puede seguir el
camino utilizado por Struts o WebWork utilizando por ejemplo
“empleado.jsf?id=#{emp.id}”, no se necesita comunicación del estado de los componentes
entre páginas.
2-Struts
¿Cuál es el contexto de aplicación ideal del framework y para qué tipos de proyectos es
altamente recomendado pensar en su framework como medio para resolver el problema
planteado?
Si se necesitan utilizar tanto Portlets como páginas complejas con demasiadas cosas
ocurriendo a la vez, entonces Struts no funcionará o será demasiado tedioso de aplicar.
De los otros frameworks analizados, ¿ha probado alguno de ellos? En caso afirmativo,
Struts está un tanto fuera de moda y no es “cool”. Realmente se puede hacer cualquier
cosa que se desee utilizando Struts, ya sea tomándolo en su estado natural o con la
ayuda de extensiones. Las limitaciones estarán dadas en mayor medida por el equipo de
desarrollo y no tanto por el framework.
3-Tapestry
¿Cuál es el contexto de aplicación ideal del framework y para qué tipos de proyectos es
altamente recomendado pensar en su framework como medio para resolver el problema
planteado?
Tapestry se integra de forma sencilla a Ioc (HiveMind o Spring) lo que constituye un gran
No estoy al tanto de algún otro framework Java que supere a Tapestry. Ruby on Rails
parecería ser un caso a seguir, pero no poseo experiencia en el como para demostrarlo.
De los otros frameworks analizados, ¿ha probado alguno de ellos? En caso afirmativo,
¿cuales, y que le ha gustado de cada no? ¿que no le gusto?
Tapestry 4.0 provee un muy buen soporte para AJAX con la biblioteca de componentes
Tacos. Tapestry 4.1 incluye un número de cambios internos para proveer un soporte aun
mejor. Tapestry 5 avanzará significativamente sobre Tapestry 4. Las funcionalidades
planificadas son:
• No imposición de herencia.
1. No es testeable. Las herramientas de testing existen desde 3.0 y son parte del
framework en 4.0.
3. Posee una inclinada curva de aprendizaje. Tapestry posee una inclinada curva de
no-aprendizaje.
4. Todo se trata sobre templates. Todo se trata de estado (permitiendo a los objetos a
almacenar el estado en lugar de utilizar singletons y múltiples threads para manejar
el estado persistente entre requests.
Es realmente una muy buena influencia, ha servido para concebir Tapestry 4 y sentar
precedentes para Tapestry 5 como ser el abandono de API fijas. Creo que los templates
son innecesariamente feos.
Ruby on Rails representa una limitación en la elección: o se hacen las cosas en la forma
que propone Ruby on Rails o se está en problemas. Aunque si se siguen las
convenciones de nombres y código, se obtiene mucho entregando poco.
4-WebWork
¿Cual es el contexto de aplicación ideal del framework y para que tipos de proyectos es
altamente recomendado pensar en su framework como medio para resolver el problema
planteado?
En términos generales WebWork encaja mejor en equipos pequeños que quieren ensuciar
sus manos y conocer mucho sobres las herramientas opensource que usan. No es ideal
para programadores que prefieren un desarrollo basado en drag&drop.
WebWork recompensa a los usuarios que se toman tiempo para aprender del framework.
Por ejemplo, aquellos que conocen los pros y contras (y han leído la documentación)
pueden sencillamente crear un ActionMapper que soporte “convención” antes que
“configuración”, pudiendo hacer que URLs como:
“/project/123/suite/456/test/create” se mapee a
“com.autogenerated.actions.projects.suite.test.CreateAction” y automáticamente pase en
los parámetros projectId = 123 y suiteId = 456. Los resultados serían “[action].jsp” o
“[action]-[result].jsp” o puede ser definido usando annotations.
El punto es que WebWork es mejor cuando es utilizado como base para un framework
relacionado directamente con la aplicación en cuestión.
Por otro lado WebWork debe ser tomado en cuenta cuando se desarrolla sobre
arquitecturas orientadas a componentes extensibles e interconectables, ejemplos de esto
son JIRA, Confluence o Jive. Esto es así debido al amplio soporte de lenguajes de
templating como es Velocity, así como también soporte para tags
• Mejor documentación.
En primer lugar se considera que Ruby on Rails no puede ser comparado con la mayoría
de los frameworks. Comparar Ruby on Rails con WebWork es como comparar Hibernate
con JDBC. Uno de ellos presenta una arquitectura de capas completa y el otro es solo
una de las capas.
He usado Ruby on Rails para realizar una aplicación pequeña, y tuve que reescribirla
completamente en Java. Ruby on Rails permite alcanzar el 80% rápidamente, pero el 20%
restante toma mucho más tiempo que la primera parte.