Vous êtes sur la page 1sur 134

Tesis

Ingeniería en Informática

Plataformas de desarrollo de
aplicaciones Web orientadas a
componentes reutilizables

Alumno: Ignacio Carlos Blanco (blanconet@gmail.com)

Padrón: 81338

Profesores:

Lic. Gustavo López

Lic. Ismael Jeder


Índice

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

Figura 1: Model 2...............................................................................................................16


Figura 2: Ciclo de vida Struts.............................................................................................18
Figura 3: Ciclo de vida JSF................................................................................................20
Figura 4: Ciclo de vida WebWork ......................................................................................21
Figura 5: Ciclo de vida Tapestry ........................................................................................23
Figura 6: Secuencia de request Struts...............................................................................29
Figura 7: Herramientas ofrecidas por plataforma...............................................................52
Figura 8: Trabajos ofrecidos en Dice.com .........................................................................53
Figura 9: Trabajos ofrecidos en Dice.com que requieren Struts ........................................53
Figura 10: Búsquedas en Monster.com. Curriculums enviados.........................................54
Figura 11: Tráfico de las listas de mail...............................................................................55
Figura 12: Libros publicados disponibles en Amazon.com ................................................55
Figura 13: Abstracción de una aplicación ..........................................................................66
Figura 14: Arquitectura del modelo ....................................................................................67
Figura 15: Paquete web del modelo ..................................................................................70
Figura 16: Ejemplo de acciones.........................................................................................73
Figura 17: Ejemplo de múltiple selección...........................................................................73
Figura 18: Estructura de layout por defecto .......................................................................75
Figura 19: Ejemplo de layout por defecto ..........................................................................75
Figura 20: Ejemplo de layout por defecto con distribución en 6 columnas ........................76
Figura 21: Ejemplo inicial de layout con placeholder .........................................................76
Figura 22: Ejemplo de layout con placeholder aplicado.....................................................77
Figura 23: Ejemplo de layout con placeholder aplicado funcionando ................................77
Figura 24: Ejemplo de layout con placeholder aplicado funcionando 2 .............................78
Figura 25: Containers anidados.........................................................................................80
Figura 26: Ejemplo Validation scope 1 ..............................................................................81
Figura 27: Ejemplo Validation scope 2 .............................................................................81
Figura 28: Ejemplo Validation scope 3 .............................................................................81
Figura 29: Ejemplo Validation scope 3 .............................................................................81
Figura 30: Ejemplo Validation scope 4 .............................................................................82
Figura 31: Jerarquía de acciones ......................................................................................84
Figura 32: Jerarquía de controles de entrada ....................................................................85
Figura 33: Componente tabla ............................................................................................87
Figura 34: Componente tabla con acciones.......................................................................88
Figura 35: Componente tabla con campos editables.........................................................88
Figura 36: Componente tabla con campos seleccionables................................................89
Figura 37: Componente tabla con paginación ...................................................................89
Figura 38: Diagrama de secuencia del modelo..................................................................91
Figura 39: Diagrama de secuencia de la renderización.....................................................92
Figura 40: Front Controller.................................................................................................94
Figura 41: MVC..................................................................................................................95
Figura 42: Template View ..................................................................................................97
Figura 43: Composite ........................................................................................................98
Figura 44: Decorator ..........................................................................................................99
Figura 45: Command .......................................................................................................100
Figura 46: Arquitectura BugMetric ...................................................................................106
Figura 47: Flujo de páginas BugMetric ............................................................................109
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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.

A Gustavo López por su apoyo incondicional durante este año.

A todos aquellos que me ayudaron durante todo este tiempo.

Gracias.

Ignacio Blanco Gustavo López


1
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

1. INTRODUCCIÓN

En el presente trabajo se analizarán las plataformas de desarrollo de aplicaciones Web


existentes teniendo en cuenta su arquitectura, los servicios prestados así como también
sus fortalezas y debilidades. En base al análisis comparativo y a un conjunto de
requerimientos necesarios para el desarrollo de aplicaciones Web empresariales se
planteará una posible solución, una plataforma, que cumpla con los requerimientos y a la
vez que resuelva las debilidades encontradas en las plataformas estudiadas.

Como demostración de la plataforma desarrollada se construirá una aplicación para


verificar su uso y características.

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.

Ignacio Blanco Gustavo López


2
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

La tendencia evolutiva de la Web continúa con el advenimiento de la “Web 2.0”, un


término que indica una segunda versión de la Web, presentando un incremento notable
en la interacción con el usuario a través de las llamadas interfaces ricas de usuario.

Ejemplos

• Intranets empresariales.

• CRM (Customer Relationship Management): administración de la relación comercial


con los clientes de una empresa.

• ERP (Enterprise Resource Planning): sistemas de gestión de información que integran


y automatizan muchas de las prácticas de negocio asociadas con los aspectos
operativos o productivos de una empresa.

• SCM (Supply Chain Management): sistemas que se encargan de la planificación,


implementación y control de las operaciones relacionadas al proceso productivo.

• Editores de texto: Writely, Thinkfree.

• Planillas de datos: Google Spreadsheet.

• Clientes de correo: Google Gmail.

Tecnologías

Inicialmente, era difícil la construcción de aplicaciones sofisticadas. La primera generación


de aplicaciones Web era primitiva, en general basada en formularios con información y
aplicaciones de búsqueda. Incluso estas aplicaciones básicas requerían de un alto
seniority para su construcción.

A través del tiempo, el conocimiento necesario para construir aplicaciones ha sido


reducido. Hoy en día, es relativamente sencillo construir aplicaciones sofisticadas
utilizando las modernas plataformas y lenguajes, como ser PHP, .NET o Java.

Ignacio Blanco Gustavo López


3
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Primera generación – CGI

Common Gateway Interface (CGI) fue la tecnología reinante desde aproximadamente


1993 hasta fines de los '90 cuando los lenguajes de scripting comenzaron a ganar
importancia.

CGI trabaja encapsulando la información provista por el usuario en variables de ambiente.


Estas luego son accedidas por scripts o programas desarrollados comúnmente en Perl o
C. Estos programas procesan la información provista por los usuarios, y luego envían
código HTML con la información procesada a la salida estándar, que a su vez es
capturada por el servidor Web y pasada al usuario.

Scripting

La falta de manejos de sesiones y control de autorización por parte de CGI impidió el


desarrollo de aplicaciones Web comerciales con esa tecnología.

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.

Los lenguajes de script tienen algunas desventajas:

• La mayoría de los lenguajes no son tipados y no promueven buenas prácticas de


programación.

• 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.

• La mayoría no soporta nativamente métodos remotos o llamadas a Web services, lo


que hace difícil la comunicación entre servidores de aplicación y con Web services

Ignacio Blanco Gustavo López


4
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

externos.

De cualquier manera a pesar de las desventajas aplicaciones grandes y frecuentemente


accedidas han sido desarrolladas utilizando lenguajes de script, como ser eGroupWare
(egroupware.org), que está escrita en PHP. Además muchas aplicaciones de Internet
banking han sido desarrolladas en ASP.

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.

Plataformas de desarrollo Web

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

• Utiliza el lenguaje Java para producir aplicaciones Web.

• Permite la creación de grandes aplicaciones distribuidas.

• Provee un buen control de sesión y manejo de autorización.

• Permite la creación de aplicaciones de múltiples capas.

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

Microsoft actualizó su tecnología ASP a ASP.NET que imita a J2EE en muchas


maneras.

• Simplifica la creación de aplicaciones pequeñas a programadores que se están

Ignacio Blanco Gustavo López


5
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

iniciando y a diseñadores gráficos.

• Permite la creación de grandes aplicaciones distribuidas.

• Provee un buen control de sesión y manejo de autorización.

• Permite a los programadores la utilización de su lenguaje de programación favorito,


el que es compilado a código nativo.

La elección entre J2EE y .NET es dependiente de la plataforma. Las aplicaciones J2EE


teóricamente pueden ser ejecutadas en la mayoría de las plataformas, desde Linux a AIX,
MacOS X o Windows.

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

• No se necesita configuración especial ni cambios en las computadoras de los


usuarios.

• Bajos costos.

• Información centralizada, segura y fácil realización de backups.

Ignacio Blanco Gustavo López


6
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

• Las actualizaciones pueden ser realizadas fácil y rápidamente.

• La información es accesible para una gran audiencia en cualquier lugar del mundo.

• Información accesible las 24 horas los 7 días de la semana.

• Todo el mundo posee un navegador. Las interfaces familiares promueven el uso.

• Los usuarios pueden aprender manejando sus tiempos en la ubicación deseada.

• Compatibilidad multiplaforma.

• Menores requerimientos de memoria. Al residir y ser ejecutadas en los servidores, las


aplicaciones Web tienen demandas de memoria muchas veces menores a las
aplicaciones convencionales.

Desventajas

• Interfaces de usuario no del todo sofisticadas.

• El desarrollo demanda más tiempo debido a la complejidad inherente.

• Riesgos de seguridad.

Aplicaciones Enterprise

Definición

Una aplicación enterprise es típicamente una aplicación de software provista por un


servidor de aplicaciones que sirve simultáneamente a un gran número de usuarios, en
general a través de una red de computadoras. De esta forma se distinguen de las
aplicaciones comunes mono usuario en que son ejecutadas en la computadora
localmente y utilizadas por un usuario a la vez.

Las aplicaciones enterprise incluyen: registro de pacientes, seguimiento de envíos,


análisis de costos, seguros, servicios al cliente, administración de la cadena productiva,
planeamiento de recursos.

Ignacio Blanco Gustavo López


7
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Las aplicaciones enterprise no incluyen: inyección de combustible en automóviles,


procesadores de texto, controladores de ascensores, controladores de plantas nucleares,
sistemas operativos, compiladores o juegos.

En general se considera que el término aplicación enterprise implica un gran sistema. A


pesar de esto es importante notar que no todas las aplicaciones enterprise son grandes,
aunque provean un gran valor a las empresas.

Características

En el ámbito empresarial se necesitan aplicaciones que cumplan una serie de


características especiales que las distinguen del resto de las aplicaciones:

z Datos masivos (gran volumen) y persistentes.

z Acceso concurrente, lo que implica gran cantidad de usuarios.

z Variedad de interfaces de usuario, lo que implica diversidad en la funcionalidad


brindada.

z Integración con otros sistemas, lo que implica que comparten funcionalidad y / o


datos.

z Disonancia conceptual (modelo de datos con distintas visiones), debido a que


poseen un modelo de negocio subyacente que abarca distintos aspectos de un
Área de negocio. Por lo tanto prestan distintas funcionalidades a distintos tipos de
usuarios.

z Lógica de negocio, lo que implica procesamiento de datos.

z Manejar grandes cantidades de datos complejos relacionados directamente con las


reglas del negocio.

z Datos persistentes. Necesitan estar disponibles entre distintas corridas de la


aplicación, incluso a través de varios años. Pudiendo incluso cambiar el software
que maneja los datos y estos migrarse de un software a otro.

Ignacio Blanco Gustavo López


8
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

z Acceso concurrente de grandes cantidades de personas. Para las aplicaciones


convencionales este número es en general de menos de cien, pero las aplicaciones
Web hace que el número crezca órdenes de magnitud. Aun tratándose de pocos
usuarios accediendo al sistema está el problema del acceso de dos personas
distintas accediendo a los mismos datos de una forma que puede causar errores.

z Grandes cantidades de interfaces de usuario. Para manejar grandes cantidades de


información se necesitan grandes cantidades de pantallas; es común hablar de
cientos de pantallas distintas en un sistema mediano.

z Variedad de usuarios. Éstos varían desde aquellos usuarios regulares a aquellos


ocasionales, y en general poseen escasa experiencia técnica. De esta forma la
información debe ser presentada de distintas formas según el propósito.

z Existencia de procesamiento batch.

z Integración. Las aplicaciones enterprise raramente viven aisladas, es usual que


deban ser integradas con otras aplicaciones enterprise diseminadas a lo largo del
negocio. A su vez las distintas aplicaciones son construidas en diferentes épocas
con diferentes tecnologías.

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:

z Dificultades en la separación de la capa de presentación de la lógica de negocio.

z Aplicaciones no escalables, lo cual es un requerimiento de facto en la aplicaciones


empresariales.

z Incompatibilidad de navegadores (cada proveedor implementa los estándares de


forma distinta, lo que dificulta aún más la situación).

z Dificultades para obtener en las aplicaciones Web comportamientos clásicos de


aplicaciones stand-alone.

Ignacio Blanco Gustavo López


9
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

z Gran cantidad de dificultades en torno al diseño de la navegación de las


aplicaciones.

z 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.

z Inconvenientes en la integración del trabajo de los desarrolladores y los


diseñadores gráficos.

Carácter del problema

El “mercado” presenta una gran cantidad de plataformas de desarrollo Enterprise, lo que


dificulta la elección de las mismas sin detenerse un tiempo considerable en cada una,
hecho que se opone a los tiempos demandados por el negocio.

Motivación para resolverlo

El problema planteado presenta un desafío para quienes se proponen resolverlo. Como


veremos en el siguiente apartado “Estado de la cuestión” existen numerosas soluciones a
los problemas presentados pero ninguna los resuelve de la forma que se pretende en este
trabajo.

En el presente trabajo se pretenden resolver distintos problemas utilizando como eje las
siguientes pautas:

z Separar totalmente la lógica de negocio de la presentación.

z Homogeneizar el desarrollo de aplicaciones Web empresariales buscando


características comunes y resaltarlas.

z Construir aplicaciones reutilizando componentes previamente realizados.

z Extraer funcionalidades comunes de las aplicaciones y convertirlas en

Ignacio Blanco Gustavo López


10
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

componentes que puedan ser utilizados en futuras aplicaciones.

z Integrar el trabajo diario de los desarrolladores con el realizado por diseñadores


gráficos.

z Permitir la integración al desarrollo Web de programadores provenientes de otras


plataformas.

Pasos a seguir

Para lograr el cometido, se investigarán en primer lugar las plataformas existentes y se


analizará la forma en que resuelven parcial o totalmente los problemas enunciados.

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.

Ignacio Blanco Gustavo López


11
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

2. ESTADO DE LA CUESTIÓN

Presentación de plataformas a comparar

A continuación se presentará la información recogida que se utilizó para establecer la


situación actual de los trabajos en investigación y desarrollo relacionados directamente
con el objetivo de este trabajo.

Se analizarán en profundidad una basta cantidad de plataformas de desarrollo con el


objeto de comprenderlas, analizarlas y compararlas entre sí.

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

Ignacio Blanco Gustavo López


12
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

z .NET

c .NET Framework

c Mono

z PHP

c Prado

c CakePHP

z Ruby

c Ruby on Rails

Ignacio Blanco Gustavo López


13
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

En particular se analizarán aquellos realizados en el lenguaje Java por poseerse una


mayor experiencia con el mismo.

Experiencia

Struts: 1 año de experiencia.

JSF: sólo he realizado pruebas de concepto.

WebWork: sin experiencia.

Tapestry: 2 años de experiencia, desde la versión 3.0 hasta la 5.0.

Características generales

Las plataformas a analizar son:

z Apache Struts V 1.X(struts.apache.org)

z Sun Java Server Faces (JSF) V 1.X(java.sun.com/javaee/javaserverfaces/)

z Opensymphony WebWork V 1.X ( www.opensymphony.com/webwork)

z Apache Tapestry V 4.0(tapestry.apache.org).

Se han escogido estas plataformas debido a que:

z Poseen una amplia aceptación en el mercado.

z Son plataformas desarrolladas íntegramente en el lenguaje Java.

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.

Ignacio Blanco Gustavo López


14
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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).

MVC es utilizado para separar los datos de su presentación. Los desarrolladores de


Smaltalk se dieron cuenta que era una mala idea tener los datos y la vista de un sistema
altamente acoplados debido a que cualquier cambio ya sea en la vista o en los datos
debía ser reflejado en el otro. MVC mitiga este problema, separa las partes del sistema
dependiendo su función en: Modelo, Vista y Controlador.

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.

La Vista es encargada de mostrar la información. En el ejemplo de la planilla, se pueden


ver los número ya sea en una grilla, un gráfico de tortas o barras. Los números son los
mismos, solo la representación visual es la que cambia. La grilla se puede convertir en
gráfico o viceversa sin modificar el valor de los números.

El Controlador es el mecanismo a través del cual la vista y el modelo se comunican. En el


ejemplo, puede ser el teclado o el mouse. En cualquier caso, el controlador cambia el
valor mostrado por la vista y también el de 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

Cuando se traslada el problema presentado en las aplicaciones “tradicionales” al entorno


Web, el deseo que se tiene es el mismo: separar la lógica de negocio de la interfaz de
usuario. MVC fue diseñado teniendo a las aplicaciones tradicionales en mente, donde la

Ignacio Blanco Gustavo López


15
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

porción de la interface de usuario es rica en comportamientos y posibilidades. Las


aplicaciones Web son diferentes debido a que la interfaz es renderizada utilizando HTML
(últimamente se ha comenzado a adoptar la plataforma Adobe Flash utilizando
plataformas de desarrollo como Adobe Flex u OpenLazlo.

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.

El escenario típico de Model 2 se ve en la Figura 1.

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

Si bien Model 2 es un paradigma ideal para la construcción de aplicaciones Web, a

Ignacio Blanco Gustavo López


16
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

medida que los desarrolladores construyen aplicaciones y se vuelven más


experimentados, descubren que hay partes que pueden ser usadas una y otra vez. A su
vez los desarrolladores se han dado cuenta que esas partes pueden ser generalizadas y
combinadas para formar partes genéricas más grandes.

Los patrones de diseño ayudan a construir estos tipos de artefactos reutilizables


permitiendo que una vez que se posee una colección de artefactos, se da origen al
principio de un framework (plataforma/marco de desarrollo).

Una plataforma de desarrollo (framework) provee la infraestructura para el desarrollo de


aplicaciones. De la misma forma que los cimientos y la estructura que sobre ellos se
construye facilita la construcción de edificios, las plataformas brindan un esqueleto que
puede ser complementado con las partes específicas de una aplicación.

Características particulares

A continuación se presentan las características particulares de cada una de las


plataformas a analizar a modo de tener una primera visión de cada una para luego, en la
sección siguiente, poder profundizar y ponderar características comunes relacionadas
directamente con el problema en cuestión permitiendo así la comparación de las mismas.

Struts

Struts es una plataforma de desarrollo open source gratuita para la construcción de


aplicaciones Web usando el patrón Model 2. [WEB-2]

Fue creado originalmente por Craig McClanahan y donado a la Apache Software


Foundation en 2000. Inicialmente formó parte del proyecto Jakarta soportado por Apache
para luego convertirse en un top-level project en 2005.

Struts está diseñado para ayudar a los desarrolladores a crear aplicaciones Web
utilizando una arquitectura MVC.

La plataforma presenta tres conceptos principales:

z Un servlet controlador encargado de dirigir los pedidos a las clases de tipo Action

Ignacio Blanco Gustavo López


17
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

provistas por el desarrollador de la aplicación.

z Un conjunto de librerías de tags para JSP, y el soporte adecuado en el


controlador que asiste al desarrollador para permitirle crear aplicaciones basadas
en formularios.

z Clases utilitarias para el parseo de XML, populación automática de las propiedades


de los JavaBeans utilizando la API de reflection y mensajes internacionalizables.

Struts es la plataforma por defecto en la actualidad utilizada para la construcción de


aplicaciones Web ya que funciona de forma correcta con las aplicaciones tradicionales
REST así como también con las últimas tecnologías como ser SOAP y AJAX.

El flujo de información básico de una aplicación que utiliza Struts se muestra en la Figura
2.

Figura 2: Ciclo de vida Struts

El flujo de información, como se ve es similar al de las aplicaciones que utilizan Model 2.


Todos los pedidos son dirigidos a un único controlador que es parte de la plataforma.
Este controlador provee numerosos servicios a la aplicación, como ser: pool de
conexiones a la base de datos y direccionamiento automático de pedidos. El controlador
crea las clases Action que son construidas por el desarrollador para realizar la tarea de
negocio correspondiente. A su vez estas acciones heredan de la clase Action propia de

Ignacio Blanco Gustavo López


18
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Struts.

Este es un perfecto ejemplo de reutilización, el controlador está diseñado para crear


subclases de Action. Éste aspecto de struts está basado en el patrón de diseño
Command, que permite la parametrización de peticiones.

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.

En resumen, Struts es una plataforma de desarrollo liviana, cuyo objetivo principal es


facilitar la construcción de aplicaciones Web usando Model 2.

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]

JSF se establece como un estándar para la construcción de interfaces de usuario


ubicándose en el lado del servidor.

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.

La tecnología JSF incluye:

z Un conjunto de APIs para la representación de componentes gráficos y el manejo


de su estado, captura de eventos y validación de entradas, definición de
navegación de páginas, y soporte para internacionalización y accesibilidad.

z Una librería de tags de JSP para poder utilizar los componentes de JSF en

Ignacio Blanco Gustavo López


19
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

páginas JSP.

El flujo de información básico de una aplicación que utiliza JSF se muestra en la Figura 3.

Figura 3: Ciclo de vida JSF

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.

Ignacio Blanco Gustavo López


20
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

WebWork

WebWork es una plataforma de desarrollo Web open-source para construir aplicaciones


Model 2. Es similar en su filosofía a Struts y a Tapestry. [WEB-7]

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).

El flujo de información básico de una aplicación que utiliza WebWork se muestra en la


Figura 4.

Figura 4: Ciclo de vida WebWork

WebWork implementa el patrón conocido como “Pull HMVC”, que significa “Pull

Ignacio Blanco Gustavo López


21
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Hierarchical Model-View-Controller”, lo cual es una versión propia de Model 2 donde el


“pull” indica que la vista es encargada de solicitar al controlador información del modelo
sobre demanda. Esto es distinto a la forma en que Model 2, recordemos que el
controlador es encargado de brindarle a la vista información del modelo. En el caso de
WebWork la vista entiende que información necesita y para esto debe esperar que el
controlador la ponga a su disposición. Esta arquitectura requiere la presencia de
repositorios que brinden los datos disponibles para todas las vistas.

La parte “hierarchical”, jerárquica, describe el repositorio de los datos de la vista.

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 desarrollo Web open-source escrita en el lenguaje Java.


Fue desarrollado por Howard Lewis Ship y es parte del proyecto Jakarta de Apache.
[Ship, 2004] [Tong-2005] [WEB-3]

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.

El desarrollo utilizando Tapestry está orientado a objetos, propiedades y métodos y no


URLs y parámetros de HTTP. Esto es logrado abstrayendo los detalles de bajo nivel de
las aplicaciones Web.

El flujo de información básico de una aplicación que utiliza Tapestry se muestra en la


Figura 5.

Ignacio Blanco Gustavo López


22
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Figura 5: Ciclo de vida Tapestry

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.

La plataforma define el flujo de la lógica de la aplicación a través de documentos XML y


objetos propios.

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

Ignacio Blanco Gustavo López


23
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

para renderizar la misma al usuario.

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.

Los documentos de especificación (de aplicación y páginas) son documentos XML. El


template se escribe utilizando lenguaje HTML convencional con porciones que son
reemplazables pero permitiendo previsualización de las páginas sin necesidad de iniciar
ningún servidor de aplicaciones. No es una vista basada en templates como ser Velocity
o JSP, en cambio se utiliza HTML como contenedor de componentes que luego son
reemplazados por controles.

Ignacio Blanco Gustavo López


24
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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]

El conjunto de características constituyen el criterio de evaluación, que luego se


ponderará para proceder a comparar teóricamente las plataformas.

Criterio de evaluación

A continuación se presentan las características que se compararán:

Grillas/Tablas

Facilidad para implementar grillas o tablas con paginación y ordenamiento.

Soporte para Ajax

¿Incluye soporte por defecto? ¿Es sencillo de usar?

Bookmark

¿Permite la plataforma que los usuarios guarden en su navegador la URL en la que


trabajan habitualmente y puedan ingresar directamente?

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?

Ignacio Blanco Gustavo López


25
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Post y redirección

¿Cómo maneja la plataforma el problema de posts duplicados?

Integración con herramientas de Inversión de Control

¿Soporta la plataforma integración con herramientas de Inversión de Control en la capa


de negocio?

Internacionalización

¿Cómo es el soporte provisto para internacionalización y cuán sencillo es acceder a los


mensajes internacionalizados desde los controladores?

Decoración de páginas

¿Qué tipos de mecanismos de decoración/composición de páginas soporta la plataforma?

Herramientas

Existencia de herramientas (Entornos Integrados de Desarrollo) que soporte la plataforma.

Marketing

Si se aprende la plataforma, ayuda en la búsqueda laboral. ¿Cuál es la demanda de


especialistas en la plataforma?

Componentes reutilizables

¿Promueve la plataforma la construcción de componentes reutilizables?

Adaptación de nuevos recursos a un equipo de trabajo

Suponiendo que los equipos rotan frecuentemente, se analiza la curva de aprendizaje


para un recurso nuevo en el equipo teniendo en cuenta que desconoce la tecnología pero
que el resto del equipo posee conocimientos sólidos en la tecnología.

Ignacio Blanco Gustavo López


26
Plataformas de desarrollo de aplicaciones Web orientadas a 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 Tiempo en el mercado de la solución.

z Frecuencia de releases.

Markup estático y dinámico

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?

Mapeo de requests a lógica de negocio

¿Cómo se da el mapeo lógico de las URL a clases lógicas?

Definición del ciclo de vida estándar de requests. Personalizaciones posibles.

Acceso a recursos

¿Soporta el API estándar J2EE de acceso a recursos (JNDI)?

Posibilidades de Inyección de dependencias o Inversión de control.

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?

Mapeo a tecnologías de vistas alternativas.

Ignacio Blanco Gustavo López


27
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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.

Programación “en el molde”

¿Cuánto induce la plataforma a programar en “moldes”?, esto es, el uso de la plataforma


permite generalizar la forma de resolver los problemas.

Modelo de la capa de Presentación

¿Cómo se representan los elementos de la Vista? ¿Cómo es el binding de los elementos


de la Vista con el modelo de datos? ¿Cómo se maneja la conversión y validación?

Análisis de herramientas en estudio

A continuación se compararán funcionalidades de las plataformas en estudio:

1-Struts

Las facilidades de desarrollo que ofrece son:

• Lógica de navegación entre páginas

• Binding entre java y el HTML

• Internacionalización

• Validación de entradas

• Independencia del motor de visualización

• Maquetación

Ignacio Blanco Gustavo López


28
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Lógica de navegación entre páginas

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.

• ActionServlet: Es el servlet controlador.

• ActionForm: Encapsulan los parámetros de las peticiones de los clientes


presentándolos como datos de un formulario. Representan los datos de entrada de
la acción a realizar. Un formulario se puede compartir entre varias peticiones de
manera que se pueda ir llenando de a partes antes de invocar a la acción.

Figura 6: Secuencia de request Struts

Ignacio Blanco Gustavo López


29
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

1. El cliente solicita una página que contiene datos a completar (no mostrado).

2. El servidor le envía la página (no mostrado).

3. El cliente, con los datos completados envía de regreso la página. El ActionServlet


verifica la ruta con la que se lo invocó y extrae el path de esa ruta y busca en los
actionMappings cual es la Acción a invocar y que formulario necesita recibir como
entrada.

4. El controlador crea o reutiliza el Formulario dependiendo el ámbito en que es ejecutada


la petición, carga los datos en el formulario, los valida y luego crea la acción y le pasa el
formulario como parámetro.

5. La acción recibe el formulario y con sus datos invoca a las reglas del negocio
(generalmente delegadas en otros objetos).

6. A partir de la respuesta recibida, carga los valores de salida y selecciona la siguiente


vista a enviar.

La inteligencia del controlador se define en un archivo xml llamado struts-config.xml. En


este archivo se guardan los mapeos, las acciones y los formularios existentes con los que
trabajará el framework. Un ejemplo del XML sería el siguiente:

<?xml version="1.0" encoding="ISO-8859-1" ?>


<!DOCTYPE struts-config PUBLIC ... >
<struts-config>
<form-beans>
<form-bean name="loginForm" type="com.empresa.LoginForm" />
</form-beans>
<action-mappings>
<action path="/inicio" forward="/jsp/inicio.jsp" />
<action path="/login" forward="/jsp/login.jsp" />
<action path="/slogin" type="com.empresa.LoginAction"
name="loginForm" scope="request" validate="true"
input="/jsp/login.jsp">
<forward name="exito" path="/jsp/inicio.jsp" />
<forward name="falla" path="/jsp/login.jsp" />
</action>
<action path="/salir" type="com.empresa.SalirAction">
<forward name="exito" path="/jsp/salir.jsp" />
</action>
</action-mappings>
<message-resources parameter="resources.application" />
</struts-config>

Ignacio Blanco Gustavo López


30
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

En esta configuración se definen un formulario llamado loginForm que es de la clase


com.empresa.LoginForm y que se utiliza como entrada de la acción slogin. Luego se
definen cuatro acciones; 2 sólo redireccionan y las otras dos tienen su implementación en
las clases LoginAction y SalirAction. Todas las acciones tienen definido un path de acceso
para poder realizar el mapeo entre la URL y la acción. Por otro lado se ve que los
resultados posibles de la acción slogin (LoginAction) son éxito o falla que redirigen a
diferentes vistas. De la misma manera, la acción salir tiene un único resultado posible que
es éxito y redirige a la vista salir.jsp. Por último, se utiliza el xml para notificarle al
framework que existe un archivo de recursos para los mensajes llamado
resources.application.

Binding entre java y HTML

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:

• struts-bean: manejo de los beans a los que tiene acceso la página.

• struts-html: renderiza los componentes HTML comunes.

• struts-logic: permite direccionar el flujo de ejecución de la página según


condiciones.

• struts-nested: permite el anidado de componentes.

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.

Ignacio Blanco Gustavo López


31
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Por ejemplo, si en el form HTML hay una entrada texto que se debe guardar en un bean

<html:text property="nombre">

en el bean de formulario asociado al action deben existir los correspondientes

public string getNombre()


public string setNombre()

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.

Por ejemplo, si se desea recorrer una colección de tiendas y el nombre de su responsable


imprimiendo sus valores se podría hacer así:

<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

Struts brinda soporte para internacionalización extendiendo la funcionalidad que ya


provee Java. Permite internacionalizar una aplicación utilizando archivos de texto
conteniendo conjuntos de datos con el formato “clave=valor” y referenciando estas claves
en los archivos de la vista

Ignacio Blanco Gustavo López


32
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

De esta manera, escribiendo en un archivo de texto (denominado en este caso


recursos.properties):

...
app.titulo=Página Principal
form.Nombre=Nombre
form.Apellido=Apellido
boton.enviar=Enviar
....

es posible referenciarlos en el HTML de la siguiente manera

<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

Ignacio Blanco Gustavo López


33
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

agregando las reglas de validación en un archivo de configuración denominado validation-


rules.xml y expresando las restricciones de los campos de cada formulario en el archivo
validation.xml.

Un ejemplo de archivo validation-rules.xml en que se define una función de validación


denominada validador1 sería el siguiente:

<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>

y un ejemplo de archivo validation.xml donde al formulario FormInicio se le establece que


el campo nombreusuario será requerido sería así:

<form-validation>
<formset>
<form name="FormInicio">
<field property="nombreusuario" depends="required">
<arg0 key="forms.nombreusuario" />
</field>
</form>
</formset>
</form-validation>

De esta manera se puede observar que la validación de entradas se mantiene de manera


externa a la aplicación java y es posible agregar o quitar restricciones sin volver a
compilar.

Independencia del motor de visualización

Struts en principio es independiente del motor de visualización aunque generalmente se


elija JSP para mostrar las vistas. Existen formas de que Struts envíe las vistas para que
sean procesadas por motores de plantillas como velocity, transformadores de estilos de
documentos XSLT u otros frameworks de presentación como JSF. Por lo tanto Struts no
está ligado a un motor de visualización particular sino que puede convivir con varios de
estos, incluso utilizándolos en simultáneo.

Ignacio Blanco Gustavo López


34
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Maquetación

La maquetación de la aplicación WEB es facilitada a través de Struts Tiles, un plugin que


permite componer a partir de porciones de página, la página definitiva que será enviada al
cliente. La composición de las partes se puede definir de tres maneras:

• A través de un xml

• Dentro de las páginas jsp

• Programáticamente desde las Actions

Algunos aspectos interesantes para mencionar son el soporte de internacionalización


(composición de partes según el Locale); las composiciones se pueden heredar y
redefinir; es posible tener varias composiciones y seleccionar una de acuerdo a una clave.

2-Tapestry

Desarrollar con Tapestry permite:

• Transparencia en la construcción de las vistas

• Binding entre java y html

• Manejo de eventos

• Construcción de componentes

• Validación de entradas

• Internacionalización

Transparencia en la construcción de las vistas

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.

Ignacio Blanco Gustavo López


35
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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:

<input type="text" jwcid="@TextField" value="ognl:inputValue"/>

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.

Binding entre Java y HTML

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()

En OGNL equivalente sería:

elCarro.itemCarro[0].producto.precio

El OGNL se utiliza para vincular valores y métodos con propiedades y manejadores de


eventos respectivamente. Por otro lado, cada página, además de un html tiene otras dos
partes: una especificación y una clase asociada. El archivo de especificación posee la
extensión .Page y es un xml que indica cuál es la clase que se hará cargo del template y
cuáles son los tipos de las propiedades a utilizar.

Así, un ejemplo con las 3 partes de una página se verían así:

HTML

<html>
<head>
<title>Ejemplo</title>

Ignacio Blanco Gustavo López


36
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

</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

public abstract class Clase extends BasePage {


public abstract String getValor();

public abstract void setValor(String valor);

public void enviar(IRequestCycle cycle) {


....
}
}

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

El manejo de eventos se realiza a través de la suscripción de listeners a los componentes


que lanzan dichos eventos. En el ejemplo anterior se puede ver de qué manera se indica
al formulario que el método enviar() es encargado de escuchar los eventos que este
genera.

<form jwcid="@Form" listener="ognl:listeners.enviar">

Ignacio Blanco Gustavo López


37
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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 jwcid="@FieldLabel" field="component:userName">Nombre:</label>


<input jwcid="userName@TextField" value="ognl:userName"
validators="validators:required" displayName="Nombre" size="30" />

En este ejemplo le estamos diciendo a la entrada de texto que tendrá asignado un


validador que obliga que haya texto ingresado al momento de enviar el form.

Inicialmente, este código se renderizará como

<label for="userName">Nombre:</label>
<input name="userName" id="userName" value="" size="30" />

Sin embargo, si al enviar el form, no se completó el contenido del campo userName, el


código se renderizará de esta manera

<font color="red">
<label for="userName">Nombre:</label>
</font>
<input name="userName" id="userName" value="" size="30" />
&nbsp;
<font color="red">**</font>

Resultando en:

Nombre: _____________ **

Otra forma de asignar validadores es enlazando los parámetros en la especificación de la

Ignacio Blanco Gustavo López


38
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

página o del componente mediante el elemento binding.

<page-specification>
...
<component id="inputPassword" type="TextField">
<binding name="validators"
value="validators:required,minLength=4" />
</component>
</page-specification>

En este caso se indica que el componente inputPassword requerirá un valor de entrada


con una longitud mínima de 4.

Internacionalización

Para la internacionalización Tapestry utiliza lo que denomina catálogos de mensajes que


vendrían a ser algo similar a los ResourceBoundles de java donde se guardan pares de
cadenas con el formato clave=valor. Cada componente puede tener un set de catálogos
de mensajes. Estos catálogos se nombran con el mismo nombre que el componente pero
su extensión es .properties. Si una clave no se encuentra en ninguno de los catálogos
Tapestry no informa ningún error sino que genera un valor propio.

Para indicar una referencia a una clave dentro del HTML se utiliza la palabra message

<html jwcid="@Shell" title="message:titulo">

Otra manera de hacer lo mismo es a través del elemento span de HTML

<span key="titulo">Un Título</span>

Esta segunda opción es más transparente para los diseñadores y no requiere del prefijo
message.

3-JSF

Desarrollar con JSF permite:

• Lógica de navegación entre páginas

• Binding entre la vista y los beans de negocio

Ignacio Blanco Gustavo López


39
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

• Manejo de eventos

• Internacionalización

• Validación de entradas

• Independencia del dispositivo de presentación

• Construcción de componentes

Lógica de navegación entre páginas

El punto de entrada a la aplicación es el FacesServlet, que se encarga de controlar el


ciclo de vida de cada petición. JSF permite definir la lógica de navegación a través de uno
o más archivos de configuración (faces-config.xml). Dicha lógica se construye a través de
reglas de navegación. Cada regla se activa según se cumpla el patrón indicado en el
elemento from-view-id.

<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.

Es posible definir casos que se activen ante la ejecución de determinadas acciones y


opcionalmente del resultado que estas devuelvan.

Por ejemplo, en la siguiente configuración se muestran dos ejemplos activados en caso

Ignacio Blanco Gustavo López


40
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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>

En este caso, si en buscador.jsp se presionara un botón asociado al método buscar del


bean UnBean, se realizaría la búsqueda y en caso que la operación sea exitosa la
próxima vista a mostrar sería resultado.jsp pero en caso contrario se mostraría busqueda-
error.jsp.

Binding entre la vista y los beans de negocio

El modelo de componentes permite el enlace de valores (value binding), de métodos


(method binding) y de componentes (component binding).

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

Ignacio Blanco Gustavo López


41
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

de expresiones como #{objeto.dicc[“clave”]}, #{objeto.array[4]},


#{objeto.propBooleana==true}, #{objeto.unNum*5+3}, etc.

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

Por último, el enlace de componentes sirve para vincular directamente un componente de


interfaz con una propiedad de un bean de manera de poder manejarlo
programáticamente. El vínculo se realiza a través del atributo binding de los componentes
que lo tienen. El objeto enlazado debe ser una propiedad de un bean que pueda leerse y
escribirse y debe descender de UIComponent.

Manejo de Eventos

JSF implementa un modelo que permite la notificación mediante eventos y la suscripción

Ignacio Blanco Gustavo López


42
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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.

Al retrasar la difusión de los eventos al finalizar la fase se asegura el correcto


procesamiento de todo el árbol de componentes que permiten dejar dicho árbol en un
estado consistente para el momento en el que se envían los eventos.

Internacionalización

La internacionalización de JSF está construida sobre la base del soporte que ya brindaba

Ignacio Blanco Gustavo López


43
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

java, la especificación de Servlets y la de JSPs.

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>

El locale se puede establecer programáticamente llamando a UIViewRoot.SetLocale().

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

<f:loadBundle basename=”mensajes.properties” var=”mensajes” />

y luego utilizar las claves precedidas por el nombre que se le dio al recurso al cargarlo

<h:outputText value=”#{mensajes.titulo}” />

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.

Por ejemplo la clave javax.faces.validator.LongRangeValidator.MINIMUM que por defecto


tiene un valor como “Value is less than allowable minimum of ‘’{0}’’”. puede sobrescribirse
y localizarse si se desea.

Validación de entradas

La inteligencia de la validación de entrada reside en los Validadores (Validators). Un


validador se encarga de realizar comprobaciones sobre el valor un componente durante la
fase Process Validations. A Cada componente que recibe la entrada de valores por parte

Ignacio Blanco Gustavo López


44
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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.

Para registrar un validador en un componente, se lo debe declarar en la vista

<h:inputText id="nombre" value="#{usuario.nombre}">


<f:validateLength minimum="5" maximum="25" />
</h:inputText>

o de manera programática mediante el método addValidator().

Validación a nivel de aplicación:

Además de las validaciones de entradas, es posible realizar validaciones a nivel de


aplicación o negocio. Supongamos que el existe un formulario que posee un campo
donde se ingresa el nombre de una persona y un botón que tiene asociado un método
mostrar() que envía a una página donde muestra sus datos.

<h:form id=”fromPersona”>
<h:inputText id=”nombrePersona” value=”persona.nombre” />
<h:message for=”nombrePersona”>
<h:commandButtonvalue ="#{ msg.aceptar }" action="#{UnBean.mostrar}"
/>
</h:form>

Luego, en el método mostrar se realiza la validación mediante esPersonaValida y en caso


de no pasar la validación se carga el mensaje y se lo envía a la vista para ser mostrado
por el componente h:message.

public string mostrar()


{
if (esPersonaValida(persona.nombre))
{
... /* Ejecuta las reglas de negocio */
return “exito”;
}
else
{
// Obtengo el contexto
FacesContext context = FacesContext.getCurrentInstance();
// Obtengo el ResourceBoundle para mostrar

Ignacio Blanco Gustavo López


45
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

// 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”;
}
}

Independencia del dispositivo de presentación

La codificación de los valores de los componentes para mostrarlos en la vista y la


decodificación necesaria de los valores que llegan de las peticiones varía dependiendo
del dispositivo. En JSF, esta codificación/decodificación se puede realizar de dos
maneras, utilizando un modelo de implementación directa o utilizando un modelo de
implementación delegada. En el modelo de implementación directa cada componente
posee la lógica para codificarse y decodificarse a si mismo. En cambio, cuando se utiliza
el modelo de implementación delegada, esta lógica se deposita en el “Renderizador” que
cada componente tiene asociado y que se especifica en la propiedad RenderedType. Con
la primera opción se facilita la creación de componentes pero con la segunda se pueden
crear componentes que, dependiendo la situación, se le presenten al usuario de diferente
manera. Por ejemplo se puede indicar que se utilice un Renderizador determinado para
las peticiones que provienen desde un celular o que se presenten de manera especial
para un idioma predeterminado.

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

Valorización de las características elegidas. Tomando como base las características

Ignacio Blanco Gustavo López


46
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

definidas se las valoriza utilizando la siguiente escala:

Símbolo Descripción

- No cumple

+ Cumple

Plataforma Grillas/Tablas Resultado

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.

JSF Existen componentes para generar grillas o tablas con paginación y +


ordenamiento. Esto es producto de la arquitectura orientada a componentes
de la plataforma. A pesar de esto, este componente y otros de este tipo no
estan disponibles con la plataforma sino que hay que conseguirlos en Internet.

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.

Plataforma Soporte para Ajax Resultado

Struts No posee soporte por defecto, hay que implementarlo de forma personalizada -
o utilizar tag libraries que soporten AJAX.

Ignacio Blanco Gustavo López


47
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

JSF No posee soporte para Ajax, se recomienda el uso de ICEfaces y Ajax4JSF -

WebWork No posee soporte por defecto, hay que implementarlo de forma personalizada -
o utilizar tag libraries que soporten AJAX.

Tapestry Soporta llamadas al servidor mediante listeners de elementos de la vista. +

Plataforma Bookmark Resultado

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 +

Plataforma Validación Resultado

Struts Utiliza Commons Validator, lo que provee una solución suficientemente +


madura.

JSF Posee una validación completa presente en los componentes de entrada. +


Además de validación presenta soporte para la conversión de tipos.

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 +

Ignacio Blanco Gustavo López


48
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

con mensajes descriptivos.

Plataforma Testeabilidad Resultado

Struts Existe soporte, StrutsTestCase. +

JSF Las clases pueden ser fácilmente testeadas. +

WebWork Permite la utilización de mocks (EasyMock, jMock) +

Tapestry En principio se dificulta el testing debido a que las páginas de Tapestry son -
abstractas.

Plataforma Post y redirección Resultado

Struts Permite que un mensaje viva a través de una redirección. +

JSF Requiere una solución personalizada. -

WebWork Requiere una solución personalizada. -

Tapestry Requiere que se lance una Excepción para redireccionar. +

Plataforma Integración con herramientas de Inversión de Control Resultado

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.

Ignacio Blanco Gustavo López


49
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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.

Plataforma Internacionalización Resultado

Struts Utiliza un ResourceBundle único por locale. +

JSF Requiere que se declare un ResourceBundle por página. +

WebWork Invoca un archivo distinto por cada página. +

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”>

Plataforma Decoración de páginas Resultado

Struts Se puede utilizar junto con Tiles, pero requiere configuración en cada página. +

Se puede utilizar junto con SiteMesh, el cual presenta una instalación y


posterior uso más sencillos.

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.

Tapestry SiteMesh no es soportado/recomendado para usar con Tapestry. Permite la +


creación de componentes Border que entregan una terminación a SiteMesh y
estos componentes estan incluidos por defecto.

Ignacio Blanco Gustavo López


50
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Plataforma Herramientas Resultado

Struts Existen numerosas herramientas que lo soportan en los entornos de +


desarrollo. Incluso existen algunos frameworks construidos sobre estos:
Beehive's o PageFlow.

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. +

Ignacio Blanco Gustavo López


51
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

14

12

10

8
WebWork
Struts
6 Tapestry
JSF
4

0
Cantidad

Figura 7: Herramientas ofrecidas por plataforma

Plataforma Marketing Resultado

Struts Es altamente demandado y usado extensamente. +

JSF Se esta volviendo poco a poco mas popular. +

WebWork Esta ganando mercado pero se requiere en muy pocas ofertas laborales. -

Tapestry Es muy escasa su demanda. -

Ignacio Blanco Gustavo López


52
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

2000

1500

WebWork
1000 Struts
Tapestry
JSF

500

0
2004 2005 2006

Figura 8: Trabajos ofrecidos en Dice.com

150

112.5

WebWork
75 Tapestry
JSF

37.5

0
2004 2005 2006

Figura 9: Trabajos ofrecidos en Dice.com que requieren Struts

Ignacio Blanco Gustavo López


53
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Figura 10: Búsquedas en Monster.com. Curriculums enviados

800

640

480
WebWork
Struts
Tapestry
320
JSF

160

0
Cantidad

Plataforma Componentes reutilizables Resultado

Struts Se pueden escribir librerías de tags, pero utilizan html, y no son componentes -
extensibles y capaces de conservar estado.

JSF Es la base de la plataforma, basada en componentes. Se pueden extender los +


componentes provistos así también como crear nuevos.

WebWork Se pueden escribir librerías de tags, pero utilizan html, y no son componentes -
extensibles y capaces de conservar estado.

Ignacio Blanco Gustavo López


54
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Tapestry Todo es un componente. +

Plataforma Comunidad Resultado

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.

JSF El hecho de ser la solución “oficial” presentada por Sun, le da un lugar +


importante dentro de la comunidad y existen múltiples recursos de ayuda a
sus seguidores.

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”.

Figura 11: Tráfico de las listas de mail

Figura 12: Libros publicados disponibles en Amazon.com

WebWork
Mensajes por mes (2006) Struts
Tapestry
JSF

0 500 1000 1500 2000

Ignacio Blanco Gustavo López


55
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

30

22.5

WebWork
15 Struts
Tapestry
JSF
7.5

0
2007

Plataforma Madurez de la tecnología Resultado

Struts En el mercado desde 2000. +

JSF En el mercado desde 2004. +

WebWork En el mercado desde 2002. +

Tapestry En el mercado desde 2003. Presenta el inconveniente de cambiar -


drásticamente entre versiones sin respetar la compatibilidad “hacia atrás”

Plataforma Markup estático y dinámico Resultado

Ignacio Blanco Gustavo López


56
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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.

El manejo del layout puede hacerse con SiteMesh.

Plataforma Mapeo de request a la lógica de negocio Resultado

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.

La personalización se realiza a través de subclases.

JSF Maneja el ciclo de vida de requests estándar. Se personaliza mediante +


listeners por fase.

Los requests se mapean a métodos en el bean que esta detrás de la página.

La personalización se realiza mediante la inyeccion de configuración y


servicios.

WebWork Utiliza las virtudes de XWork para realizar el mapeo de requests a Actions. -

Provee configuración del flujo básico por defecto.

Ignacio Blanco Gustavo López


57
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

La personalización se realiza mediante interceptors.

Tapestry El ciclo de vida se maneja a través de ApplicationServlet. +

Los requests se mapean a listeners implementados en la página.

La personalización se realiza mediante la inyeccion de configuración y


servicios.

Plataforma Model tier resource access Resultado

Struts “Trae tu propio modelo” , no provee facilidades para el acceso a recursos. -

JSF Utiliza Manager Beans. A su vez permite la integración con otros frameworks +
de IoC utilizando APIs de extensibilidad.

WebWork Permite el uso de XWork, Spring y Pico. +

Tapestry Permite el uso de Spring e HiveMind. El ultimo es utilizado por el core mismo. +

Plataforma Navegación de páginas Resultado

Struts Cada Action retorna un ActionForward. Cada ActionForward esta mapeado a -


una vista.

La navegación por defecto es a RequestDispatcher.forward().

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. +

Se puede navegar a una variedad de destinos como ser Actions,

Ignacio Blanco Gustavo López


58
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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.

Los valores de las IPage pueden ser inyectados.

Plataforma Wizards Resultado

Struts No provee por defecto un componente o grupo de componentes necesarios -


para la creación de Wizards. Existe sin embargo un componente de terceros
struts-flow que soluciona la navegación, pero no presenta una forma de que
un wizard reciba un modelo y devuelva uno como resultado.

JSF No provee por defecto un componente o grupo de componentes necesarios -


para la creación de Wizards. Existe sin embargo un componente de terceros
Dialog Manager que es parte del proyecto Shale que esta basado en JSF.

WebWork o grupo de componentes necesarios para la creación de Wizards. -

Tapestry En la última versión 5 se presenta soporte para almacenar estado de la -


aplicación a compartir entre las diferentes páginas de un wizard. Esta
funcionalidad es realmente necesaria pero está solo presente en una versión
no liberada aún.

Plataforma Modelo de la capa de Presentación Resultado

Struts El estado de la capa de presentación se realiza a través de objetos -


ActionForm. La conversión es responsabilidad de la aplicación.

Ignacio Blanco Gustavo López


59
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Se utilizan tags JSP para representar elementos HTML.

El binding con el modelo de datos se hace a través de BeanUtils.

La validación esta a cargo de Jakarta Commons Validator, tanto cliente como


servidor.

JSF Los componentes de presentación opcionalmente se linkean a propiedades +


del bean que esta “por detrás” de la página.

El binding se realiza utilizando JSF EL.

La validación se realiza a través de Validators que estan linkeados a los


componentes.

WebWork El estado esta representado como propiedades en subclases de -


ActionSupport.

Se utilizan tags JSP para representar elementos HTML.

El binding se realiza a través de OGNL (Object Graph Navigation Language)

La validación del lado del servidor se realiza utilizando Xwork.

Tapestry El estado esta en propiedades que poseen los componentes con los que se +
construyen las páginas.

Los tags HTML con el atributo “jwcid” referencian a los componentes.

El binding se realiza utilizando OGNL.

La validación se realiza a través de Delegators linkeados al form.

Análisis de los datos obtenidos

De la evaluación anterior se observa que las siguientes características son incumplidas


por la mayoría de las plataformas analizadas:

o Grillas/tablas

Ignacio Blanco Gustavo López


60
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

o Soporte para Ajax


o Post y redirección
o Marketing
o Componentes reutilizables
o Markup estático y dinámico
o Mapeo de requests a lógica de negocio
o Navegación de páginas
o Modelo de la capa de presentación

Las características que están ausentes o no cumplidas son consideradas de vital


importancia en la construcción de aplicaciones Enterprise, esto sumado a los problemas
clásicos de la programación Web constituyen las razones principales para la búsqueda de
un modelo en el que se solucionen las mismas.

En la próxima sección se ve en detalle el planteo del problema que motiva el presente


trabajo.

Ignacio Blanco Gustavo López


61
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

3. DEFINICIÓN DEL PROBLEMA

El Problema

¿ Cuál es el problema que se pretende resolver?

Un grupo de características consideradas como “no cumplidas” por las plataformas de


desarrollo estudiadas surgen del análisis del estado del arte.

Se suman entonces estas características a las dificultades inherentes del desarrollo de


aplicaciones enterprise sobre plataformas Web; las últimas enunciadas en la Introducción
de este trabajo.

Las características no cumplidas son:

• Navegación de páginas

• Wizards

• Adaptación de nuevos recursos a un team

• Programar en el “molde”

• Adaptación a cambios en UI

• Mapeo de request a la lógica de negocio

Completando, los dificultades del desarrollo Web son:

z Dificultades en la separación de la capa de presentación de la lógica de negocio.

z Aplicaciones no escalables, lo cual es un requerimiento de facto en la aplicaciones


empresariales.

z Incompatibilidad de navegadores (cada proveedor implementa los estándares de


forma distinta, lo que dificulta aún más la situación).

Ignacio Blanco Gustavo López


62
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

z Dificultades para obtener en las aplicaciones Web comportamientos clásicos de


aplicaciones stand-alone.

z Gran cantidad de dificultades en torno al diseño de la navegación de las


aplicaciones.

z 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.

z Inconvenientes en la integración del trabajo de los desarrolladores y los


diseñadores gráficos.

¿Por qué este problema y no otro?

Se consideraron aquellas características críticas en el desarrollo de aplicaciones


enterprise sobre plataformas Web como eje del problema a resolver.

¿Cuál es su importancia en el contexto de estudio?

Dentro de las características seleccionadas podemos considerar de suma importancia en


el contexto:

Dificultades para obtener en las aplicaciones Web comportamientos clásicos de


aplicaciones stand-alone: debido a que los usuarios de aplicaciones enterprise en general
fueron usuarios de aplicaciones stand-alone es clave poder brindarles este tipo de
comportamientos sin importar que se trate de una aplicación Web. Por otro lado
comportamientos como drag & drop, u otros componentes gráficos (widgets) son útiles
para facilitar el aprendizaje de la aplicación y su relación con el modelo real.

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.

Adaptación de nuevos recursos a un team: las dimensiones de las aplicaciones enterprise

Ignacio Blanco Gustavo López


63
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

en general, requieren de equipos de trabajo mediano/grande, es por esto que la


posibilidad de incorporación de miembros durante el proceso es muy probable. Se
necesita entonces que la incorporación sea dinámica y requiera la mínima adquisición de
conocimientos posible.

Inconvenientes en la integración del trabajo de los desarrolladores y los diseñadores


gráficos: en general los diseñadores gráficos trabajan en su diseño y los programadores
en su código, lo que representan dos dimensiones ortogonales. Al momento de poner en
común y juntar en sucesivas iteraciones, alguno de los dos perfiles termina solapándose
en el otro sin ser un resultado esperado. Es por eso que se necesita que ambos perfiles
trabajen por separado y que el momento de juntar el trabajo sea lo mas simple posible y
sin resultados inesperados.

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.

Ignacio Blanco Gustavo López


64
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

4. SOLUCIÓN PROPUESTA

La Solución

¿Cómo se ha resuelto el problema?

El modelo planteado como solución al problema presentado se basa en encontrar un


factor común en las aplicaciones Enterprise de manera tal de poder crear un esqueleto o
molde de este tipo de aplicaciones y poder reutilizarlo.

La estructura común considerada como esqueleto de aplicaciones Enterprise es la


siguiente:

Ignacio Blanco Gustavo López


65
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Figura 13: Abstracción de una aplicación

En la estructura se pueden distinguir:

• Módulos: representan un conjunto de casos de uso, y representan módulos no


acoplados dentro de una aplicación, ejemplos de módulos podrían ser por un lado
un módulo de administración de usuarios y un módulo de carga de ordenes. En
este caso si bien ambos módulos comparten lógica de negocio no comparten ni
páginas ni casos de uso.

Ignacio Blanco Gustavo López


66
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

• Casos de uso: representan un conjunto de páginas con una funcionalidad


relacionada. Un ejemplo clásico de un caso de uso es un wizard. La idea
fundamental de los casos de uso es permitir por un lado reutilizar no solo una
página sino un conjunto de las mismas y el comportamiento (navegación y datos)
de las mismas.

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.

El modelo de entrada puede ser directamente el modelo de la página (MVC) o


existe la posibilidad también de decorar el mismo.

Arquitectura

QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.

Figura 14: Arquitectura del modelo

configuration

Contiene la lógica necesaria para el manejo de la configuración del framework. Incluye la

Ignacio Blanco Gustavo López


67
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

configuración de: aplicación, módulos y casos de uso.

persistence

Provee una abstracción para el manejo de la persistencia utilizando el framework


Hibernate. Entre las utilidades incluidas se pueden encontrar: consultas realizadas
mediante criterias orientadas a objetos, clases bases para la creación de objetos home o
repository y por último el concepto de object set implementado. Éste último concepto es
una forma de manejar aquellos datos que si bien no son fijos en la aplicación se parte de
una base conocida (Ej.: países), a su vez se pueden utilizar para tener datos de prueba
durante el desarrollo y contar con estos cada vez que se inicia la aplicación.

predicates

Los predicados son operadores o funciones que devuelven un valor booleano. Se


implementan predicados de las operaciones lógicas básicas (si, no, y, o) para luego ser
utilizados en la presentación para definir la visibilidad o disponibilidad de elementos.

messages

Representan una abstracción que simplifica la internacionalización de cadenas de


caracteres a lo largo de la aplicación.

constants

Se almacenan todas las constantes utilizadas por el framework y se encarga de evitar


colisiones de nombres.

closures

Incluye la representación de un closure internamente en el framework, es básicamente


una implementación del patrón Command.

models

Se implementan los modelos que son utilizados por los componentes provistos por el

Ignacio Blanco Gustavo López


68
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

framework para almacenar información en su interior (Ej.: modelo de tablas, listas de


selección).

mail

Incluye clases utilitarias para el manejo de envío de emails utilizando el framework.

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

Contiene la definición de contexto de usuario, incluye la sesión y la definición del lenguaje


del usuario actual.

security

Implementación extensible provista por el framework para el manejo de autorización y


autenticación basada en roles y perfiles.

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

Código necesario para realizar pruebas del framework.

Ignacio Blanco Gustavo López


69
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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

Es el paquete de mayor tamaño y que implementa la mayor parte de las funcionalidades


de la plataforma.

QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.

Figura 15: Paquete web del modelo

Componentes visuales

Introducción

La plataforma implementa un conjunto de componentes visuales que cubren las


necesidades básicas de cualquier aplicación. Dentro de este conjunto se encuentran
todos los controles que provee HTML (inputs, select, button, etc), así como también
algunos componentes compuestos que no son provistos por HTML (palette, table, image

Ignacio Blanco Gustavo López


70
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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

El primer componente visual que se necesita para desarrollar aplicaciones con la


plataforma propuesta.

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:

public void onNextPage1() {


QNavigation.startPage("ComponentShowCase2", null);
}

En este caso se invoca la página ComponentShowCase2 (definida así en la


especificación del módulo) y se le pasa un modelo null (sin modelo). Es así como en la
página ComponentShowCase2 se invocará el método createModel debido a que no se
recibe un modelo:

public Object createModel() {


return new Model();
}

Esta implementación básicamente retorna un modelo nuevo para que los controles tomen
de él los datos y los actualicen en él.

Ignacio Blanco Gustavo López


71
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Ahora veamos un ejemplo donde se pasa un modelo a la página siguiente:

public void onNextPage2() {


QNavigation.startPage("ComponentShowCase2", new Model());
}

A continuación se ve un ejemplo donde se implementa un listener a ser invocado en caso


de retornar la página con éxito y no se implementa en caso de error:

public void onNextPage3() {


QNavigation.startPage("ComponentShowCase2", null, new QFinalizeAction() {
public void execute(Object pageModel, Object result) {
}
}, QNullFinalizeAction.getInstance());
}

Vemos de que forma retorna la página ComponentShowCase2:

public void someListener() {


QNavigation.acceptPage(new ResultModel());
}

Por último se ve un ejemplo donde se implementan ambos listeners (éxito y error):

public void onNextPage4() {


QNavigation.startPage("ComponentShowCase2", new Model(), new
QFinalizeAction() {
public void execute(Object pageModel, Object result) {
//hago algo en caso de retornar con exito
}}, new QFinalizeAction() {
public void execute(Object pageModel, Object result) {
//hago algo en caso de error
}});
}

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;

Ignacio Blanco Gustavo López


72
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

protected void setFormPanelElements(QFormPanel form) {


lblText = QCF.messageLabel(form, "lblText", "Botón sin presionar");
lblText.setInternationalize(false);
QCF.action(form, "btnBoton", "onBoton");
}
public void onBoton() {
lblText.setKey("Botón presionado");
}

QuickTime™ and a QuickTime™ and a


TIFF (Uncompressed) decompressor TIFF (Uncompressed) decompressor
are needed to see this picture. are needed to see this picture.

Figura 16: Ejemplo de acciones

Ejemplo de múltiples combos

QPredicate paisSelected = new QValuePredicate("pais","").not();


protected void setFormPanelElements(QFormPanel form) {
QCF.comboSelector(form, "cmb1", "pais", "paises",
"").setOnChangeListener(new QMethodListener(this, "onPaisChange"));
QCF.comboSelector(form, "cmb2", "ciudad", "ciudades",
"").setHasNullElement(false).setVisible(paisSelected);
}

QuickTime™ and a
TIFF (Uncompressed) decompressor
QuickTime™ and a
TIFF (Uncompressed) decompressor are needed to see this picture.
are needed to see this picture.

Figura 17: Ejemplo de múltiple selección

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

Ignacio Blanco Gustavo López


73
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

una propiedad codigoPostal, para acceder a la misma haríamos:


usuario.getDireccion().getCodigoPostal, con OGNL en cambio accedemos como
usuario.direccion.codigoPostal. Si bien al principio resulta similar, OGNL presenta virtudes
en cuanto al manejo de excepciones por valores nulos (usuario por ejemplo).

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

Para favorecer el posicionamiento de componentes en la Vista se utilizan los Layouts,


estos son algoritmos que definen de qué manera se ubican los componentes en el
componente que los contiene.

Un Layout es una clase Java que implementa la interfaz QLayout:

public interface QLayout {


public void render(QMarkUpWriter writer, List elements);
}

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):

Ignacio Blanco Gustavo López


74
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Figura 18: Estructura de layout por defecto

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:

Figura 19: Ejemplo de layout por defecto

El código es:

protected void setFormPanelElements(QFormPanel form) {


QCF.textField(form, "txtNombre", "nombre");
QCF.textField(form, "txtApellido", "apellido");

Ignacio Blanco Gustavo López


75
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

QCF.datePicker(form, "dtpFecha", "fecha");


QCF.checkBox(form, "chkOpcion1", "opcion1");
QCF.checkBox(form, "chkOpcion2", "opcion2");
QCF.checkBox(form, "chkOpcion3", "opcion3");
QCF.checkBox(form, "chkOpcion4", "opcion4");
QCF.action(form, "btnBoton1", "onBoton1");
QCF.action(form, "btnBoton2", "onBoton2");
QCF.action(form, "btnBoton3", "onBoton3");
QCF.action(form, "btnBoton4", "onBoton4");
}

Ahora cambiamos el límite de espacios por línea a 6 por ejemplo:

Figura 20: Ejemplo de layout por defecto con distribución en 6 columnas

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:

Figura 21: Ejemplo inicial de layout con placeholder

El código es:

private String busqueda = null;


private QTextField txtBusqueda;
private QMessageLabel lblBuscado;
protected void setFormPanelElements(QFormPanel form) {
QTextField txtBusqueda = QCF.textField(form, "txtBusqueda", "busqueda");
lblBuscado = QCF.messageLabel(form, "lblBuscado", "buscado");
lblBuscado.setInternationalize(false);

Ignacio Blanco Gustavo López


76
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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);
}

Ahora al agregar el FileLayout se verá así:

Figura 22: Ejemplo de layout con placeholder aplicado

Luego:

Figura 23: Ejemplo de layout con placeholder aplicado funcionando

Ignacio Blanco Gustavo López


77
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

El funcionamiento es el mismo:

Figura 24: Ejemplo de layout con placeholder aplicado funcionando 2

El código para lograr esto es:

protected void beforeCreateDocument(QDocumentFactory factory) {


factory.setPanelCreator(new QDocumentElementCreator() {
public Object createElement(QAbstractPage page) {
return new CustomFormPanel("form");
}
});
};
class CustomFormPanel extends QDefaultFormPanel {
public CustomFormPanel(String name) {
super(name);
this.setLayout(new QFileLayout(
"/Users/blanconet/Documents/Tesis/wspTesis/tesis-
demo/uthopy/src/main/webapp/layout/showcase.html"));
}
public void doRender(QMarkUpWriter writer) {
getLayout().render(writer, getContainedControls());
}
}

Y el HTML incluyendo los placeholders es:

<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">

Ignacio Blanco Gustavo López


78
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

<tbody>
<tr valign="top">
<td width="25%">&nbsp;</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">
&nbsp;&nbsp;<a href="/advanced_search?hl=en">Advanced Search</a><br>
&nbsp;&nbsp;<a href="/preferences?hl=en">Preferences</a><br>
&nbsp;&nbsp;<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&nbsp;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:

public void render(QMarkUpWriter writer, List elements)

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.

Ignacio Blanco Gustavo López


79
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

La implementación de Composite permite el anidamiento de controles obteniéndose


configuraciones como la siguiente:

protected void setFormPanelElements(QFormPanel form) {


QGroup group1 = QCF.group(form, "grp1");
QGroup group2 = QCF.group(group1, "grp2");
QFieldSet fds1 = QCF.fieldSet(group2, "fds1");
}

QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.

Figura 25: Containers anidados

Este diseño permite que se puedan combinar los controles de casi cualquier manera para
generar nuevos componentes reutilizables.

Validation scope

El validation scope es el alcance que tienen las validaciones de un formulario. Debido a


que una misma página puede contener muchos controles y muchas zonas que son
independientes entre sí es necesario poder validar por zonas o contenedores. Esto
permite una experiencia de usuario superior permitiendo moverse entre páginas dejando
datos sin completar hasta volver a la página inicial.

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:

En primer lugar se carga la dirección presionando el botón “Dirección”:

Ignacio Blanco Gustavo López


80
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Figura 26: Ejemplo Validation scope 1

Allí se cargan los datos:

Figura 27: Ejemplo Validation scope 2

Se presiona “Guardar dirección”:

Figura 28: Ejemplo Validation scope 3

En la página inicial se ven los datos cargados:

Figura 29: Ejemplo Validation scope 3

Ignacio Blanco Gustavo López


81
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Vemos el código:

protected void setFormPanelElements(QFormPanel form) {


QGroup group1 = QCF.group(form, "grp1");
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(group2);
}
public String getDireccion() {
if (direccion == null) {
return "";
}
return direccion.getCalle() + " " + direccion.getPiso() + " ("
+ direccion.getCodigoPostal() + ")";
}
public void onDireccion() {
QNavigation.startPage("DireccionPage", null, new QFinalizeAction() {
public void execute(Object pageModel, Object result) {
direccion = (Direccion) result;
}
}, QNullFinalizeAction.getInstance());
}
}

Ahora se ve el ejemplo donde se valida el campo nombre

Figura 30: Ejemplo Validation scope 4

protected void setFormPanelElements(QFormPanel form) {


QGroup group1 = QCF.group(form, "grp1");

Ignacio Blanco Gustavo López


82
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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

Los componentes action, componen una jerarquía extensible de componentes que

Ignacio Blanco Gustavo López


83
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

realizan un llamado (sincrónico) al servidor. Este llamado invoca en el servidor un método


llamado listener que es especificado al momento de la creación del componente.

QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.

Figura 31: Jerarquía de acciones

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);

QImageAction QuickTime™ and a QCF.imageAction(form, "btnAccept", "onImage", img);


TIFF (Uncompressed) decompressor
are needed to see this picture.

QLinkSubmit QuickTime™ and a


QCF.linkSubmit (form, "btnEnabled", "onEnabled");
TIFF (Uncompressed) decompressor
are needed to see this picture.

QImageLinkSubmit QuickTime™ and a QCF.imageLinkSubmit (form, "btnEnabled",


TIFF (Uncompressed) decompressor
are needed to see this picture. "onEnabled", img);

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

Ignacio Blanco Gustavo López


84
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

momento de la carga del componente en el navegador el control se completa con los


datos presentes en el modelo del servidor.

Figura 32: Jerarquía de controles de entrada

Componente Código

QDatePicker QCF.datePicker(form, "dtpDate",


"date");

QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.

QuickTime and a QCF.textField(form, "txtCountry",


QTextField TIFF (Uncompressed) decompressor
are needed to see this picture. "country");

QuickTime and a QCF.textField(form, "txtCountry",


QTextField TIFF (Uncompressed) decompressor
are needed to see this picture. "country")
.setEnabled(QDummyPredicate.FALSE);

QComboSelector QCF.comboSelector(form,
"cmbCountry", "country",
"countries", "");
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.

Ignacio Blanco Gustavo López


85
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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.

QTextArea QCF.textArea(form, "txtComments",


QuickTime™ and a "comments");
TIFF (Uncompressed) decompressor
are needed to see this picture.

QTextArea QCF.textArea(form, "txtComments",


QuickTime™ and a "comments").setEnabled(QDummyPredic
TIFF (Uncompressed) decompressor ate.FALSE);
are needed to see this picture.

QCheckBox QuickTime™ and a QCF.checkBox(form, "chkEmail",


TIFF (Uncompressed) decompressor "email");
are needed to see this picture.
QuickTime™ and a QCF.upload(form, "uplResume",
QFileUpload TIFF (Uncompressed) decompressor "resume");
are needed to see this picture.

Palette

El componente Palette es un componente de doble lista de selección que maneja dos


modelos para representar las listas.

Componente Código

QDatePicker QCF.palette(form, "palCountries",


"countries", "countriesSelected", "");

QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.

Ignacio Blanco Gustavo López


86
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Menú

Componente Código

QMenu QMenuBar bar = new QMenuBar("menuBar");


QuickTime™ and a form.addControl(bar);
TIFF (Uncompressed) decompressor
QMenuBar are needed to see this picture. QMenu menu1 = new QMenu("archivo");
bar.addItem(menu1);
QSimpleMenuItem
QSimpleMenuItem item1 = new
QSimpleMenuItem("abrir");
item1.setListener(new QMethodListener(this,
"onItem1"));
menu1.addItem(item1);

QSimpleMenuItem item2 = new


QSimpleMenuItem("cerrar");
item2.setListener(new QMethodListener(this,
"onItem2"));
menu1.addItem(item2);

QSimpleMenuItem edicion = new


QSimpleMenuItem("edicion");
bar.addItem(edicion);

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.

Figura 33: Componente tabla

El código para generar la tabla anterior es:

QTable grd = QCF.table(form, "grdCountries", "paises");


grd.addSimpleColumn("hdrName", "nombre", false);
grd.addSimpleColumn("hdrPopulation", "poblacion", false);

También debe existir un método que retorne la colección de países:

public Collection getPaises() {


List paises = new ArrayList();
paises.add(new Pais("Argentina", 10));
paises.add(new Pais("Brazil", 100));

Ignacio Blanco Gustavo López


87
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

paises.add(new Pais("Chile", 1000));


paises.add(new Pais("Paraguay", 10000 ));
return paises;
}

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.

Figura 34: Componente tabla con acciones

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:

QTable grd = QCF.table(form, "grdCountries", "countriesList");


grd.addSimpleColumn("name", "name", false);
grd.addSimpleColumn("population", "population", false);
grd.addRowAction("btnEdit", "onEdit");
grd.addTableAction("btnNew","onNew");

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.

Figura 35: Componente tabla con campos editables

El código para conseguir esto es:

QTable grd = QCF.table(form, "grdCountries", "countriesList");


grd.addTextBoxColumn("name", "name", false);
grd.addSimpleColumn("population", "population", false);
grd.addRowAction("btnEdit", "onEdit");

Ignacio Blanco Gustavo López


88
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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.

Figura 36: Componente tabla con campos seleccionables

El código del ejemplo anterior es:

QTable grd = QCF.table(form, "grdCountries", "countriesList");


grd.setMultipleSelection("selectedCountries");
grd.addTextBoxColumn("name", "name", false);
grd.addSimpleColumn("population", "population", false);
grd.addRowAction("btnEdit", "onEdit");
grd.addTableAction("btnNew","onNew");

Por último se muestra la funcionalidad de paginado que también está presente en el


componente Table:

QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.

Figura 37: Componente tabla con paginación

El código es:

QTable grd = QCF.table(form, "grdCountries", "countriesList");


grd.setMultipleSelection("selectedCountries");
grd.addTextBoxColumn("name", "name", false);
grd.addSimpleColumn("population", "population", false);
grd.addRowAction("btnEdit", "onEdit");
grd.addTableAction("btnNew","onNew");
grd.getPaging().setPageSize(2);

Ignacio Blanco Gustavo López


89
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Cabe destacar que las funcionalidades son independientes y combinables, como se ve en


los ejemplos anteriores, a medida que se fue presentando cada funcionalidad estas no
fueron removidas, así demostrando en el último ejemplo una tabla que incluye campos de
selección, campos editables, acciones de fila, acciones de tabla y paginación.

Funcionamiento

Como se ha visto, toda la programación de la interfaz de usuario se realiza con código


JAVA, esto se plantea de esta forma para reducir al curva de aprendizaje de la plataforma
al lenguaje de programación JAVA. Es así que no se necesita conocer ninguno de los
lenguajes de programación Web como ser Javascript, HTML o CSS para poder construir
aplicaciones enterprise de calidad superior.

A su vez, el aprendizaje propiamente dicho de la plataforma abstrae al programador del


contexto Web, permitiéndole pensar en entidades de más alto nivel como ser las páginas
o casos de uso.

Ciclo de vida

Presentados ya los componentes y la arquitectura principal de la plataforma, veamos un


ejemplo en el que se muestra el funcionamiento de la plataforma, componente a
componente, desde que se envía el pedido desde el browser hasta obtenerse el
resultado:

Ignacio Blanco Gustavo López


90
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Figura 38: Diagrama de secuencia del modelo


Ignacio Blanco Gustavo López
91
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Ahora veamos un ejemplo que muestra la renderización de una página incluyendo sus componentes:

Figura 39: Diagrama de secuencia de la renderización

Ignacio Blanco Gustavo López


92
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Patrones utilizados

Durante la implementación de las distintas capas de la arquitectura de la plataforma,


distintas decisiones de diseño terminaron resultando en la aplicación de varios patrones
de diseño. A continuación se presentan los problemas de diseño junto con el/los patrones
utilizados para resolverlos: [Gamma et al, 1995] [Fowler, 2002]

Front Controller.

Tipo: presentación Web

Descripción: En aplicaciones Web complejas, existe un grupo de operaciones similares


que se realizan al momento de manejar un request. Estas operaciones incluyen
seguridad, internacionalización y proveer vistas para ciertos usuarios. Si el control de las
entradas se divide entre muchos objetos, es posible que el comportamiento se duplique;
también es complicado cambiar el comportamiento de todos los objetos en tiempo de
ejecución.

Funcionamiento: Con Front Controller se consolidan todos los requests a través de un


único objeto que atiende los pedidos. Este objeto implementa comportamiento común que
puede ser modificado en tiempo de ejecución utilizando Decorators. El objeto luego
despacha objetos Command para obtener un comportamiento particular para cada
pedido.

Utilización/Adaptación: Se implementó el patrón en la clase QApplicationServlet. Es


responsabilidad de ésta clase la recepción todas las peticiones hacia el servidor y de
redirecciona según sea necesario a la entidad que corresponda.

Tiene a cargo algunas funciones de inicialización de la aplicación.

Delega en el engine los pedidos, tanto GET como POST a la vez que inicializa el contexto
de usuario almacenado en el request.

Diagrama:

Ignacio Blanco Gustavo López


93
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Figura 40: Front Controller

MVC

Tipo: presentación Web

Descripción: es un patrón de arquitectura de software que separa los datos de una


aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El
patrón MVC se ve frecuentemente en aplicaciones Web, donde la vista es la página HTML
y el código que provee de datos dinámicos a la página, el modelo es el Sistema de
Gestión de Base de Datos y el controlador representa la Lógica de negocio.

Funcionamiento: MVC considera tres roles. El Modelo es un objeto que representa


información sobre el dominio. Es un objeto no-visual que contiene todos los datos y
comportamiento que no sean utilizadas para la UI. En la forma más pura de orientación a
objetos el Modelo es un objeto dentro de un Domain Model.

La Vista es la representación visual del modelo en la UI. Entonces si el modelo es un


objeto cliente, la Vista podría ser un marco conteniendo widgets o una página HTML
renderizada con datos del Modelo. La Vista presenta datos de solo lectura; cualquier

Ignacio Blanco Gustavo López


94
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

cambio a la información mostrada es manejado por el tercer miembro de MVC: el


Controlador. El Controlador toma las entradas del usuario, manipula el Modelo, y hace
que la Vista se actualice para mostrar estos cambios. De esta forma la UI es una
combinación de Vista y Controlador.

Utilización/Adaptación: Se implementó de la siguiente forma; el Modelo no posee


ninguna restricción sino que pueden ser POJOs (Plain Old Java Objects), objetos con
datos y comportamiento. La vista es una estructura compleja que comienza desde
QAbstractPage, clase de la que heredan todas las páginas de la plataforma, estas
representan lo que será la vista al renderizarse en HTML, Javascript y CSS y contienen
lógica presente en la UI. Por último el Controlador, es el QApplicationServlet que
implementa Front Controller, por lo cual es el único punto de acceso de todos los pedidos
que luego son delegados en el engine quien a su vez delega nuevamente en el servicio
adecuado.

Diagrama:

Figura 41: MVC

Ignacio Blanco Gustavo López


95
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Template View

Tipo: presentación Web

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.

Funcionamiento: La idea básica detrás de Template View es incluir


marcadores/placeholders en HTML estático cuando se crea la página. Luego cuando la
página es solicitada, los marcadores/placeholders son reemplazados por resultados
generados dependiendo del llamado, como ser datos de una base de datos o incluso
controles HTML.

De esta manera el layout de la página es el mismo y el contenido cambia en ciertas


secciones previamente definidas. Esto facilita el trabajo con diseñadores gráficos que
generalmente utilizan editores WYSIWYG. Al agregar estos marcadores el diseño no se
ve modificado en absoluto.

Utilización/Adaptación: Se implementó mediante uno de los tipos de layout provistos,


QFileLayout. Este layout permite que a partir de un contenido estático HTML se agreguen
placeholders del formato ${NOMBRE_DEL_COMPONENTE} y luego estos marcadores
sean reemplazados por los componentes correspondientes y también se agregue el
Javascript necesario del componente.

De esta forma, se puede trabajar en simultáneo y sin interferir con el trabajo realizado por
el diseñador gráfico.

Diagrama:

Ignacio Blanco Gustavo López


96
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Figura 42: Template View

Composite

Tipo: estructural

Descripción: Se componen objetos en una estructura de árbol para representar


jerarquías completas. Composite permite a un cliente tratar a los objetos individuales y
compuestos uniformemente.

En aplicaciones gráficas o de construcción de esquemas los usuarios pueden agrupar


componentes simples para formar componentes complejos, quienes a su vez pueden re
agruparse.

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.

Utilización/Adaptación: La clase base de los controles, QControl implementa Composite,

Ignacio Blanco Gustavo López


97
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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:

Figura 43: Composite

Tipo: estructural

Descripción: Muchas veces se pretende agregar responsabilidades a objetos


individuales, no a una clase. En general esto se ve al programar interfaces gráficas, por
ejemplo: se desea agregar un borde o un comportamiento como el desplazamiento a
cualquier control de la UI.

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.

Funcionamiento: El Decorator implementa la interfaz del componente que decora, de

Ignacio Blanco Gustavo López


98
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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.

En definitiva, Decorator permite agregar responsabilidades dinámicamente a un objeto a


la vez que presenta una alternativa a la herencia para la extensión de funcionalidades.

Utilización/Adaptación: Se implementó principalmente en las páginas, mediante la


interfaz QPageRenderListener que permite agregar funcionalidad a las páginas en dos
momentos: antes y después de la renderización de la misma. Es así como se pueden
agregar bordes a las páginas, a la vez que se permite agregar autenticación antes de la
carga de la misma y también cambiar al vista en base al pedido.

Diagrama:

Figura 44: Decorator

Command

Tipo: comportamiento

Ignacio Blanco Gustavo López


99
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Descripción: Encapsula una petición en un objeto, permitiendo así parametrizar a los


clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder
deshacer la operaciones.

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.

Utilización/Adaptación: Se implementó para definir un comportamiento ante el retorno


de páginas o casos de uso mediante la interfaz QFinalizeAction, que incluye el método
execute que recibe el modelo de la página que invocó y el modelo de resultado.

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:

Figura 45: Command

Ignacio Blanco Gustavo López


100
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Builder

Tipo: creacional

Descripción: Separa la construcción de un objeto complejo de su representación. Se


oculta la implementación de la instanciación de un objeto complejo o se pretenden
agrupar las reglas de instanciación de objetos complejos.

Funcionamiento: Se define una clase que se encarga de construir los objetos complejos.

Utilización/Adaptación: Debido a la complejidad inherente de los objetos que componen


la UI se definió una clase para la construcción de los mismos, QCF. La clase se encarga
de construir a los elementos visuales así como también de agregarlos a la estructura de la
página.

Domain Model

Tipo: lógica de dominio

Descripción: Para resolver la complejidad de la lógica de dominio en un sistema de


información, se aplica el patrón Domain Model. Este consiste en crear, en la Capa de
Dominio, un modelo de objetos del dominio que incorpore datos y comportamiento. De
este modo, tendremos objetos que representan datos de nuestro dominio y que contienen
reglas de negocio asociadas a estos datos (comportamiento).

Funcionamiento: Se debe agregar una capa de objetos a la aplicación que modele el


área de negocio en la que se está trabajando. Se crearán objetos entonces que imiten los
datos del negocio y objetos que capturen las reglas que el negocio usa. La mayoría de los
datos y procesos se combinan para que los procesos estén junto con los datos con los
que trabajan.

Utilización/Adaptación: La plataforma, presenta la posibilidad y fomenta la utilización de


modelos que contengan datos y comportamiento para las páginas. De esta forma los
controles pueden estar vinculados con los datos del modelo; las validaciones y acciones
de negocio también están vinculadas con el modelo. Por ejemplo, un modelo podría ser
una dirección la cual tendría los datos y el comportamiento, es así como los controles de

Ignacio Blanco Gustavo López


101
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

la pantalla que cargan la dirección estarían vinculados al modelo y la validación de fechas


estaría también en el modelo.

Query Object

Tipo: mapeo objeto-relacional

Descripción: Un Query Object es un interprete estructurado en un objeto, el cual permite


transformar en sentencias SQL mediante atributos de los objetos de negocio. De esta
manera los criterios se realizan a partir de clases y los atributos que componen a las
mismas, en contraposición a los formados con columnas pertenecientes a tablas que
hacen dependiente el criterio al esquema de base de datos utilizado.

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.

Utilización/Adaptación: Se implementó una jerarquía de queries, junto con criterias. Las


queries incluyen QCriteria, QOrderCriteria y QOperatorCriteria, siendo las QCriterias
aquellas que especifican la condición de filtro dentro de una consulta (where), las
QOrderCriteria son aquellas que especifican el ordenamiento de los resultados (order by)
y las QOperatorCriterias especifican las operaciones sobre los resultados (SUM, AVG,
etc).

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.

Ignacio Blanco Gustavo López


102
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Repository

Tipo: mapeo objeto-relacional

Descripción: Todo sistema que posee un dominio complejo se beneficia de la existencia


de una capa que separe al dominio de objetos de los detalles de la base de datos.

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.

Funcionamiento: El cliente construye una consulta y se la envía al Repository, luego el


Repository ejecuta la consulta y devuelve los objetos que satisfacen en una colección.

Utilización/Adaptación: Se implementó mediante la clase abstracta QAbstractHome, en


ésta se implementan las consultas más utilizadas y generales: buscarTodos y cargar. De
esta forma el Repository o Home de cualquier clase de dominio hereda de
QAbstractHome e implementa un único método mandatario que identifica la clase que se
está consultando, luego los métodos para cargar un objeto o todos los de su tipo están
implementados en la clase base.

Ignacio Blanco Gustavo López


103
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

5. RESULTADOS O VERIFICACIÓN EXPERIMENTAL

Casos de aplicación

Para verificar la solución presentada se implementa una parte de una aplicación


Enterprise que permite la carga de bugs encontrados en la prueba de un sistema. Se
presenta un caso de uso real de la solución: un Trabajo Profesional de ésta Facultad, aún
en desarrollo, utiliza este modelo como base para el desarrollo de una aplicación
solicitada por las autoridades de la Facultad.

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.

Se desarrolla una aplicación completa debido a que se consideran intrascendentes los


resultados que se pudieran obtener de realizar una aplicación trivial para poder verificar
experimentalmente los resultados obtenidos.

“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.

La aplicación soporta múltiples proyectos, incluyendo a su vez múltiples módulos por


proyecto; permitiendo así la adaptación a toda clase de proyecto informático.

Requerimientos

El siguiente escenario describe el flujo de una orden a través del sistema. La secuencia
de eventos es la que sigue:

Ignacio Blanco Gustavo López


104
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

1. Se crea un proyecto

2. Se agregan módulos al proyecto incluyendo líneas de código del mismo y una


descripción

3. Se agregan recursos al proyecto

4. A medida que se encuentran fallas o defectos se crean las mismas en el proyecto


indicando el tipo y estado de las mismas

5. Periódicamente se obtienen métricas basadas en la información previamente


ingresada al sistema.

Casos de uso

Como complemento de la descripción anterior, se escriben los requerimientos como casos


de uso.

z Creación de proyectos – Describe como se dan de alta proyectos para ser


utilizados como base de generación de métricas.

z Modificación de proyectos - Describe como se actualizan los datos de los


proyectos como ser creación de nuevos módulos o actualización de datos de los
recursos del proyecto.

z Carga de problemas – Describe como se cargan y actualizan periódicamente las


fallas o defectos en el sistema.

z Modificación de issues – Describe como se actualizan los issues, por ejemplo


cambio de estado.

z generación de métricas – Describe como se obtienen distintos tipos de métricas


basadas en la información previamente ingresada.

Arquitectura

Una visión de alto nivel de la arquitectura de la aplicación puede verse en la Figura 46.

Ignacio Blanco Gustavo López


105
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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.

Figura 46: Arquitectura BugMetric

La interfaz de usuario está implementada a través de una capa de presentación Web. El


negocio de la aplicación consiste en varios componentes que son responsables del
manejo de proyectos e issues.

La capa de persistencia es responsable del acceso a la base de datos.

Caso de uso “Creación de proyectos”

Ignacio Blanco Gustavo López


106
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

z El usuario administrador crea un proyecto indicando nombre y una descripción del


mismo.

z El usuario administrador crea módulos del proyecto:

c El usuario administrador crea módulos indicando el nombre y las líneas de


código del mismo.

z El usuario administrador crea recursos asignados al proyecto:

c El usuario administrador crea recursos indicando el nombre de los mismos.

z El usuario administrador confirma la creación a partir de la cual los datos del


proyectos quedan almacenados para ser actualizados en el futuro y obtener
métricas a partir de estos datos.

Caso de uso “Modificación de proyectos”

z El usuario administrador escoge de la página general de los proyectos el proyecto


a modificar.

z El usuario administrador modifica los módulos:

c El usuario administrador crea/actualiza módulos existentes.

c El usuario administrador crea/actualiza recursos existentes.

z El usuario administrador confirma los datos creados/actualizados.

Caso de uso “Carga de problemas”

z El usuario de control de calidad elige un proyecto y luego un modulo dentro del


proyecto.

z El usuario de control de calidad selecciona su nombre para indicar que el fue quien
reporto.

z El usuario de control de calidad ingresa una descripción del problema.

Ignacio Blanco Gustavo López


107
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Caso de uso “Modificación de problemas”

z El usuario de control de calidad escoge de la página general de los problemas el


problema a modificar.

z El usuario de control de calidad modifica el problema:

c El usuario de control de calidad cambia el estado del problema.

c El usuario de control de calidad cambia la descripción del problema.

z El usuario de control de calidad confirma los datos creados/actualizados.

Caso de uso “generación de métricas”

z El usuario elige un proyecto.

z El usuario elige una métrica.

z El usuario genera la métrica.

Ignacio Blanco Gustavo López


108
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Flujo de páginas

Figura 47: Flujo de páginas BugMetric

Conclusiones

Luego de haber desarrollado una aplicación completa se destaca la simplicidad que


otorga la solución propuesta adaptándose al negocio de forma directa.

La navegación de páginas se vio simplificada por el modelo presentado por la solución,


así como también la forma de intercambiar datos entre páginas.

En la implementación se utilizaron funcionalidades avanzadas como ser la definición de


un layout para darle un “look & feel” personalizado al ejemplo.

Ignacio Blanco Gustavo López


109
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

“Sistema de Coordinación Docente”

Descripción

Es un sistema para al coordinación de Docentes durante su ciclo de vida en un


Departamento. Dicho sistema debería permitirle a los responsables de cada uno de los
departamentos poder manejar las personas de las cuales se encuentra a cargo. Creando,
modificando, eliminando o actualizando designaciones, y asignándole funciones de
distinta índole (ya sea de docencia, coordinación, administrativa, etc) durante los distintos
cuatrimestre que se van a ir dando.

Otra de las tareas a ofrecer, es la posibilidad de consultar toda la información histórica


utilizada para sustentar las funciones primordiales del sistema.

Conclusiones

La principal ventaja encontrada fue la posibilidad de generar pantallas muy rápidamente,


de manera sencilla y sin la necesidad de preocuparse por manejar código HTML. Esto
último facilitó mantener un estilo unificado en las pantallas a lo largo de todo el sistema.
Otra cuestión que resultó muy útil fue la facilidad que ofrece la plataforma para reutilizar
pantallas, lo cual agilizó y acortó tiempos de desarrollo.

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.

Como conclusión final se puede decir que la utilización de la plataforma permite la


posibilidad de desarrollar la aplicación de forma rápida, sencilla y muy práctica.

Ignacio Blanco Gustavo López


110
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

6. CONCLUSIONES Y FUTURAS LÍNEAS DE


INVESTIGACIÓN

6.1 Conclusiones

Para justificar el modelo obtenido como solución, se plantea un análisis de trazabilidad


que mapea los problemas presentados como motivación de este trabajo y las
funcionalidades presentes en la solución obtenida:

ƒ Navegación de páginas

Se resuelve de forma clara y extensible mediante la conceptualización de una aplicación


en módulos, casos de uso y páginas. Este modelo permite la reutilización de conjuntos de
páginas agrupados en casos de uso, los que a su vez pueden ser invocados
análogamente a una función recibiendo un parámetro (modelo) y devolviendo un valor de
retorno (modelo de resultado).

ƒ Wizards

La construcción de wizards se ve resuelta utilizando el concepto de casos de uso, debido


a que dentro de un caso de uso se manejan páginas, entre las cuales se puede conservar
un mismo modelo e ir modificándose entre las distintas páginas. A la vez se permite
desde cualquier página retornar a un origen común resolviéndose así la navegación
dentro del wizard.

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.

ƒ Adaptación de nuevos recursos a un team

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

Ignacio Blanco Gustavo López


111
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

programación y sin exigirle otro lenguaje o estándar (HTML, CSS, Javascript).

ƒ Programar en el “molde”

Debido a que la solución esta basada en problemas y requerimientos de las aplicaciones


Enterprise, es directo tomar partes/módulos de aplicaciones Enterprise y modelarlas con
los elementos provistos por la plataforma, como ser módulos, casos de uso o páginas.
Luego una vez que se estructuró la aplicación, se puede trabajar en reflejar los
requerimientos en cuanto a interfaz de usuario rápidamente para poder presentarle al
cliente una versión funcional la que puede ser luego completada con la lógica de negocio
desacoplada de la UI y por último, en caso de requerirse, aplicar un diseño gráfico
complejo a la solución inicial.

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.

ƒ Mapeo de request a la lógica de negocio

Este problema es solucionado utilizando listeners, que abstraen la forma en que se


mapea el request al negocio. Es transparente, ya que los controles que disparan eventos
simplemente declaran el nombre del listener y este es invocado tanto en la página como
en el modelo.

ƒ Dificultades en la separación de capa de presentación y lógica de


negocio.

La capa de presentación queda totalmente desacoplada de la lógica de negocio, ya que la

Ignacio Blanco Gustavo López


112
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

capa de presentación delega la lógica de negocio en el controlador, que puede ser la


página misma o un controlador separado de la página. A su vez al ser la capa de
presentación generada en base a código Java, se tiene total control sobre que lógica se
traslada a la presentación, en general validaciones de entradas de usuarios.

ƒ Incompatibilidad de navegadores

Cada proveedor implementa los estándares de forma distinta, lo que dificulta aún más la
situación.

Al presentar de forma abstracta la presentación, todos los detalles necesarios para


adaptarse a los navegadores más aceptados estan dentro de la plataforma y son
transparentes a los usuarios de la plataforma, simplificando también de esta forma la
curva de aprendizaje.

6.2 Integración con otros trabajos

Se considera de particular importancia la integración realizada entre el presente trabajo y


otros de esta misma casa.

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.

6.3 Mejoras futuras

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

Ignacio Blanco Gustavo López


113
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Web de aplicaciones Enterprise, esto implica que para convertir la plataforma en un


producto que sirva de base a aplicaciones productivas, se deberían revisar los siguientes
puntos:

• Performance: mediante pruebas de balance y carga.

• Revisión de código: es necesario revisar el código totalmente en busca de errores.

• Incremento de test unitario y funcional: para darle una cobertura suficiente al


código que otorgue estabilidad ante cambios.

• 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.

• Alternativas en el almacenamiento de los datos de usuario y páginas en la sesión:


actualmente los datos se almacenan en sesión, lo que puede ser un problema si el
tamaño de los datos crece y el número de usuarios también. De esta forma se
pueden analizar alternativas como ser, almacenar en el cliente (campos ocultos) o
en una base de datos.

• Agregado de widgets visuales: para completar con los componentes presentados


se podría agregar un sinnúmero de widgets, como ser slidebar, colorpicker. Al
mismo tiempo se podrían agregar efectos de animación como también soporte para
“drag&drop”.

• Soporte para la generación de ABMs de forma automática partiendo de un objeto


de dominio acompañado de annotations o una descripción del mapeo a un método
de persistencia.

• Convertir el proyecto en Opensource: luego de realizar las revisiones necesarias,


incluyendo una revisión de licencias, sería deseable publicar el proyecto en algún
repositorio Opensource de manera tal de obtener el soporte de la comunidad. Esto

Ignacio Blanco Gustavo López


114
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

contribuiría a mejorar la calidad del mismo así como también se obtendría una
respuesta de aceptación.

• Creación de herramientas que soporten la plataforma: ejemplos pueden ser plugins


para entornos de desarrollo como Eclipse, Intelli-J, etc. También se podrían crear
arquetipos de Maven para la generación de proyectos con al configuración básica.

Ignacio Blanco Gustavo López


115
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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

[Ashmore, 2004] Derek C. Ashmore, The J2EE Architect's Handbook, How to be a


successful technical architect for J2EE applications, DVT Press, 2004

[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

[Beck, 2000] Kent Beck, Extreme Programming Explained, Addison-Wesley, 2000

[Sierra, 2002] Katht Sierra, Bert Bates, Sun Certified Programmer & Developer for Java 2,
Osborne, 2002

[Ship, 2004] Howard L. Ship, Tapestry in Action, Manning, 2004

[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.

[McClanahan, 2005] Craig R. McClanahan, The Evolution of Web Application


Architectures, 2005.

[McClanahan, 2006] Craig R. McClanahan, The State of Web Frameworks, 2006.

Ignacio Blanco Gustavo López


116
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

[Raible, 2006] Matt Raible, Java Web Framework Sweet Spots, 2006.

[Richardson, 2006] Chris Richardson, POJOs in Action, 2006.

[Montaldo, 2005] Diego Montaldo, Patrones de Diseño de Arquitecturas de Software


Enterprise, 2005.

[Fowler, 2002] Martin Fowler, Patterns of Enterprise Application Architecture, 2002.

[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/

Ignacio Blanco Gustavo López


117
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

8. ANEXOS

Contextos de aplicación ideal

En esta sección se construyó utilizando un cuestionario común que fue realizado a los
autores: [Raible, 2006]

o JSF, Jacob Hookom

o Struts Action 1, Don Brown

o Tapestry, Howard Lewis Ship

o WebWork, Patrick Lightbody

Las preguntas son las siguientes:

1. ¿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?

2. ¿En qué tipo de escenarios no utilizaría su framework? ¿Recomendaría otro en ese


escenario? ¿En caso de hacerlo, cuál sería?

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?

4. ¿Cuál es el futuro del framework? ¿Cuál de las próximas funcionalidades


simplificará el esfuerzo requerido por los desarrolladores? ¿Soporta Ajax
nativamente? ¿Si no lo hace, está pensando en agregar soporte?

5. ¿Existe algún mito sobre su framework que le gustaría cambiar?

6. ¿Qué piensa de Ruby on Rails?

Ignacio Blanco Gustavo López


118
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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?

Cuando se desea traer funcionalidades disponibles en una aplicación de escritorio a un


navegador Web con la confianza de una especificación estándar y grandes cantidades de
funcionalidades de terceros. JSF se enfoca principalmente en brindar una plataforma que
sea escalable tanto en requerimientos como en complejidad.

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.

¿En qué tipo de escenarios no utilizaría su framework? ¿Recomendaría otro en ese


escenario? ¿En caso de hacerlo, cuál sería?

Debido a que JSF se encarga de mantener el estado de la UI por el desarrollador, agrega


un sobre trabajo tal que hace que no sea ideal para sitios web grandes de solo lectura. En
esos casos, probablemente sería más razonable utilizar Struts porque existen un gran
conocimiento en el ambiente de esta herramienta.

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

Puntos a favor: existe un gran conocimiento de esta herramienta en el mercado.

Puntos en contra: La separación entre estado y comportamiento en este framework es de


la vieja escuela.

WebWork

Ignacio Blanco Gustavo López


119
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

Puntos a favor: Mejor que Struts en la práctica.

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

Puntos a favor: Grande en innovación, puede manejar UIs complejas.

Puntos en contra: Para ser un framework basado en componentes, sigue atado al


paradigma de página/acción.

¿Cuál es el futuro del framework? ¿Cuál de las próximas funcionalidades simplificara el


esfuerzo requerido por los desarrolladores? ¿Soporta Ajax nativamente? Si no lo hace,
¿está pensando en agregar soporte?

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).

¿Existe algún mito sobre su framework que le gustaría cambiar?

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

Ignacio Blanco Gustavo López


120
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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.

¿Qué piensa de Ruby on Rails?

Es tan bueno como WebWork pero eleva al grado n el beneficio de la convención en la


utilización de frameworks.

Todos los frameworks pueden comenzar a sacar ventaja de las convenciones.

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?

La documentación, amplia comunidad de usuarios, libros y soporte. Si se desea utilizar un


framework que es bien conocido y en donde conseguir recursos o entrenar a los mismos
es sencillo, entonces la opción es Struts.

A pesar de que otros proyectos son tecnológicamente superiores en diferentes formas, la


distancia es menor a la que se suele pensar. La capa web es suficientemente sencilla y
de aprendizaje directo.

¿En qué tipo de escenarios no utilizaría su framework? ¿Recomendaría otro en ese


escenario? En caso de hacerlo, ¿cuál sería?

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.

Un framework orientado a componentes funcionaría mejor en el último caso. Tanto JSF o


Tapestry aplicarían perfectamente en este escenario.

De los otros frameworks analizados, ¿ha probado alguno de ellos? En caso afirmativo,

Ignacio Blanco Gustavo López


121
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

¿cuales, y que le ha gustado de cada no? ¿que no le gusto?

He probado todos y en general cada uno es bueno en su manera.

¿Cuál es el futuro del framework? ¿Cuál de las próximas funcionalidades simplificara el


esfuerzo requerido por los desarrolladores? ¿Soporta Ajax nativamente? Si no lo hace,
¿está pensando en agregar soporte?

Struts 2, basada en WebWork 2, abrirá nuevas posibilidades. Ya provee soporte para


componentes AJAX pero se está buscando simplificar el desarrollo, soporte para JSF,
continuations y lenguajes de scripting.

¿Existe algún mito sobre su framework que le gustaría cambiar?

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.

¿Qué piensa de Ruby on Rails?

Es un buen ejemplo de un proyecto focalizado en la productividad de los desarrolladores


sin recaer en herramientas de drag&drop. Se esperan aprender lecciones y aplicarlas en
Struts 2.

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?

El verdadero poder de Tapestry está dado en la aplicación en proyectos mediano/grandes


(aunque la diversión está presente aun en proyectos pequeños). En este tipo de proyectos
se notarán las mejoras que permite la creación y reutilización de componentes.

Tapestry se integra de forma sencilla a Ioc (HiveMind o Spring) lo que constituye un gran

Ignacio Blanco Gustavo López


122
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

bonus para equipos que desean producir código confiable y testeable.

¿En que tipo de escenarios no utilizaría su framework? ¿Recomendaría otro en ese


escenario? En caso de hacerlo, ¿cual sería?

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?

No he trabajado suficiente fuera de Tapestry en los últimos años. Me gustaría aprender


otros frameworks, especialmente Ruby on Rails.

¿Cual es el futuro del framework? ¿Cual de las próximas funcionalidades simplificara el


esfuerzo requerido por los desarrolladores? ¿Soporta Ajax nativamente? Si no lo hace,
¿está pensando en agregar soporte?

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 más clases abstractas.

• No imposición de herencia.

• Annotations aplicadas a atributos en lugar de a métodos abstractos.

• No más XML, solo templates y annotations.

• Classloader inteligente, toma los cambios de las clases automáticamente y en


forma eficiente.

• API mínima más allá de annotations.

• Construcción de componentes orientada a aspectos.

Ignacio Blanco Gustavo López


123
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

¿Existe algún mito sobre su framework que le gustaría cambiar?

1. No es testeable. Las herramientas de testing existen desde 3.0 y son parte del
framework en 4.0.

2. Es un monólogo. Existen cantidades de committers activos de Tapestry y una


comunidad muy activa.

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.

¿Que piensa de Ruby on Rails?

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.

A pesar de eso la filosofía presentada es similar a la de Microsoft (usa nuestras


herramientas o …). En cambio la filosofía de Java es “no sabemos como vas a usar la
herramienta entonces soportamos cualquier posibilidad”.

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

Ignacio Blanco Gustavo López


124
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

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

¿En que tipo de escenarios no utilizaría su framework? ¿Recomendaría otro en ese


escenario? En caso de hacerlo, ¿cual sería?

WebWork es pobre en cuanto al manejo de estado y wizards. Si se desean escribir largos


wizards, tal vez la mejor opción es JSF.

En lo que respecta a la curva de aprendizaje es destacable la pobre e incompleta


documentación disponible en la actualidad (tutoriales, FAQ, referencias, etc).

¿Cual es el futuro del framework? ¿Cual de las próximas funcionalidades simplificara el


esfuerzo requerido por los desarrolladores? ¿Soporta Ajax nativamente? Si no lo hace,
¿está pensando en agregar soporte?

En Struts 2.0 (Struts + WebWork) se espera:

• Mejor documentación.

Ignacio Blanco Gustavo López


125
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables

• Soporte para estándares (OGNL).

• Soporte para AJAX (más widgets).

¿Existe algún mito sobre su framework que le gustaría cambiar?

• Requiere demasiada configuración: no es así, se pueden conseguir convenciones


similares a las presentadas por Rails.

• Mala documentación: es parcialmente cierto, ya que la misma está siendo


mejorada.

¿Que piensa de Ruby on Rails?

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.

Ignacio Blanco Gustavo López


126

Vous aimerez peut-être aussi