Post on 27-Sep-2018
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
Ignacio Blanco Gustavo López 1
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 2
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 3
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 4
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 5
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 6
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 7
• 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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 8
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:
Datos masivos (gran volumen) y persistentes.
Acceso concurrente, lo que implica gran cantidad de usuarios.
Variedad de interfaces de usuario, lo que implica diversidad en la funcionalidad
brindada.
Integración con otros sistemas, lo que implica que comparten funcionalidad y / o
datos.
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.
Lógica de negocio, lo que implica procesamiento de datos.
Manejar grandes cantidades de datos complejos relacionados directamente con las
reglas del negocio.
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 9
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.
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.
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.
Existencia de procesamiento batch.
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:
Dificultades en la separación de la capa de presentación de la lógica de negocio.
Aplicaciones no escalables, lo cual es un requerimiento de facto en la aplicaciones
empresariales.
Incompatibilidad de navegadores (cada proveedor implementa los estándares de
forma distinta, lo que dificulta aún más la situación).
Dificultades para obtener en las aplicaciones Web comportamientos clásicos de
aplicaciones stand-alone.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 10
Gran cantidad de dificultades en torno al diseño de la navegación de las
aplicaciones.
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.
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:
Separar totalmente la lógica de negocio de la presentación.
Homogeneizar el desarrollo de aplicaciones Web empresariales buscando
características comunes y resaltarlas.
Construir aplicaciones reutilizando componentes previamente realizados.
Extraer funcionalidades comunes de las aplicaciones y convertirlas en
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 11
componentes que puedan ser utilizados en futuras aplicaciones.
Integrar el trabajo diario de los desarrolladores con el realizado por diseñadores
gráficos.
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 12
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:
Java
Struts
JSF
WebWork
Tapestry
Turbine
Shale
Trails
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 13
.NET
.NET Framework
Mono
PHP
Prado
CakePHP
Ruby
Ruby on Rails
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 14
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:
Apache Struts V 1.X(struts.apache.org)
Sun Java Server Faces (JSF) V 1.X(java.sun.com/javaee/javaserverfaces/)
Opensymphony WebWork V 1.X ( www.opensymphony.com/webwork)
Apache Tapestry V 4.0(tapestry.apache.org).
Se han escogido estas plataformas debido a que:
Poseen una amplia aceptación en el mercado.
Son plataformas desarrolladas íntegramente en el lenguaje Java.
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 15
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 16
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 17
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:
Un servlet controlador encargado de dirigir los pedidos a las clases de tipo Action
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 18
provistas por el desarrollador de la aplicación.
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.
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 19
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:
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.
Una librería de tags de JSP para poder utilizar los componentes de JSF en
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 20
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 21
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 22
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 23
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 24
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 25
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?
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 26
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 27
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:
Tiempo en el mercado de la solución.
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 28
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 29
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 30
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>
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 31
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 32
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 33
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 34
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 35
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 36
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>
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 37
</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">
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 38
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" /> <font color="red">**</font>
Resultando en:
Nombre: _____________ **
Otra forma de asignar validadores es enlazando los parámetros en la especificación de la
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 39
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 40
• 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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 41
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 42
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 43
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 44
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 45
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 46
// 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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 47
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.
-
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 48
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 +
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 49
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.
-
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 50
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.
+
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 51
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. +
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 52
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. -
Cantidad0
2
4
6
8
10
12
14
WebWorkStrutsTapestryJSF
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 53
Figura 8: Trabajos ofrecidos en Dice.com
Figura 9: Trabajos ofrecidos en Dice.com que requieren Struts
2004 2005 20060
37.5
75
112.5
150
WebWorkTapestryJSF
2004 2005 20060
500
1000
1500
2000
WebWorkStrutsTapestryJSF
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 54
Figura 10: Búsquedas en Monster.com. Curriculums enviados
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.
-
Cantidad0
160
320
480
640
800
WebWorkStrutsTapestryJSF
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 55
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
Mensajes por mes (2006)
0 500 1000 1500 2000
WebWorkStruts TapestryJSF
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 56
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
20070
7.5
15
22.5
30
WebWorkStrutsTapestryJSF
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 57
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.
-
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 58
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,
+
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 59
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.
-
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 60
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 61
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 62
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:
Dificultades en la separación de la capa de presentación de la lógica de negocio.
Aplicaciones no escalables, lo cual es un requerimiento de facto en la aplicaciones
empresariales.
Incompatibilidad de navegadores (cada proveedor implementa los estándares de
forma distinta, lo que dificulta aún más la situación).
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 63
Dificultades para obtener en las aplicaciones Web comportamientos clásicos de
aplicaciones stand-alone.
Gran cantidad de dificultades en torno al diseño de la navegación de las
aplicaciones.
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.
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 64
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 65
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:
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 66
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 67
• 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 aTIFF (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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 68
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 69
framework para almacenar información en su interior (Ej.: modelo de tablas, listas de
selección).
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 70
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 aTIFF (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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 71
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 72
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;
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 73
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 aTIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and aTIFF (Uncompressed) decompressor
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 aTIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and aTIFF (Uncompressed) decompressor
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 74
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):
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 75
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");
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 76
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);
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 77
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 78
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">
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 79
<tbody>
<tr valign="top">
<td width="25%"> </td>
<td align="center" nowrap="nowrap">
<input name="hl" value="en" type="hidden">
${txtBusqueda}<br>
${btnBuscar}
<input name="btnI" value="I'm Feeling Lucky" disabled type="submit">
</td>
<td nowrap="nowrap" width="25%"><font size="-2">
<a href="/advanced_search?hl=en">Advanced Search</a><br>
<a href="/preferences?hl=en">Preferences</a><br>
<a href="/language_tools?hl=en">Language Tools</a></font></td>
</tr>
<tr><td colspan="3" align="center">${lblBuscado}</td></tr>
</tbody></table></form><br><br>
<font size="-1"><a href="/intl/en/ads/">Advertising Programs</a>
- <a href="/services/">Business Solutions</a>
- <a href="/intl/en/about.html">About Google</a>
- <b><a href="http://www.google.com.ar/">Go to Google Argentina</a></b></font><p>
<font size="-2">©2007 Google</font>
</body>
</html>
Más allá de los layouts provistos por defecto, se pueden implementar layouts propios,
simplemente heredando de QAbstractLayout e implementando el siguiente método:
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 80
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 aTIFF (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”:
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 81
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 82
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");
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 83
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
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QCF.group(form, "grp”);
QGroup QuickTime and a
TIFF (Uncompressed) decompressorare needed to see this picture.
Fieldset
Componente Código
QFieldSet
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QCF.fieldSet(form, "fds”);
Actions
Los componentes action, componen una jerarquía extensible de componentes que
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 84
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 aTIFF (Uncompressed) decompressor
are needed to see this picture.
Figura 31: Jerarquía de acciones
Componente Código
QAction QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QCF.action(form, "btnEnabled", "onEnabled");
QAction QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.QCF.action(form, "btnDisabled",
"onDisabled").setEnabled(QDummyPredicate.FALSE);
QImageAction QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QCF.imageAction(form, "btnAccept", "onImage", img);
QLinkSubmit QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QCF.linkSubmit (form, "btnEnabled", "onEnabled");
QImageLinkSubmit QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QCF.imageLinkSubmit (form, "btnEnabled", "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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 85
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
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QCF.datePicker(form, "dtpDate", "date");
QTextField QuickTime and a
TIFF (Uncompressed) decompressorare needed to see this picture.
QCF.textField(form, "txtCountry",
"country");
QTextField QuickTime and a
TIFF (Uncompressed) decompressorare needed to see this picture.
QCF.textField(form, "txtCountry",
"country")
.setEnabled(QDummyPredicate.FALSE);
QComboSelector
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QCF.comboSelector(form,
"cmbCountry", "country",
"countries", "");
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 86
QComboSelector
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QCF.comboSelector(form, "cmbCountry", "country", "countries", ""). setHasNullElement(false);
QRadioSelector
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QCF.radioSelector(form, "cmbCountry", "country", "countries", "");
QRadioSelector
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QCF.radioSelector(form, "cmbCountry", "country", "countries", "").setHasNullElement(false);
QTextArea QuickTime™ and a
TIFF (Uncompressed) decompressorare needed to see this picture.
QCF.textArea(form, "txtComments", "comments");
QTextArea QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QCF.textArea(form, "txtComments", "comments").setEnabled(QDummyPredicate.FALSE);
QCheckBox QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QCF.checkBox(form, "chkEmail", "email");
QFileUpload QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.QCF.upload(form, "uplResume", "resume");
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
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QCF.palette(form, "palCountries", "countries", "countriesSelected", "");
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 87
Menú
Componente Código
QMenu
QMenuBar
QSimpleMenuItem
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QMenuBar bar = new QMenuBar("menuBar"); form.addControl(bar); QMenu menu1 = new QMenu("archivo"); bar.addItem(menu1); 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 aTIFF (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));
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 88
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 aTIFF (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 aTIFF (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");
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 89
grd.addTableAction("btnNew","onNew");
Otra funcionalidad destacada del componente Table es la selección de filas que permite
mostrar una grilla seleccionable:
QuickTime™ and aTIFF (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 aTIFF (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);
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 90
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:
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 91
Figura 38: Diagrama de secuencia del modelo
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 92
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 93
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:
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 94
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 95
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 96
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:
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 97
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,
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 98
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 99
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 100
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 101
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 102
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 103
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 104
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:
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 105
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.
Creación de proyectos – Describe como se dan de alta proyectos para ser
utilizados como base de generación de métricas.
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.
Carga de problemas – Describe como se cargan y actualizan periódicamente las
fallas o defectos en el sistema.
Modificación de issues – Describe como se actualizan los issues, por ejemplo
cambio de estado.
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 106
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”
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 107
El usuario administrador crea un proyecto indicando nombre y una descripción del
mismo.
El usuario administrador crea módulos del proyecto:
El usuario administrador crea módulos indicando el nombre y las líneas de
código del mismo.
El usuario administrador crea recursos asignados al proyecto:
El usuario administrador crea recursos indicando el nombre de los mismos.
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”
El usuario administrador escoge de la página general de los proyectos el proyecto
a modificar.
El usuario administrador modifica los módulos:
El usuario administrador crea/actualiza módulos existentes.
El usuario administrador crea/actualiza recursos existentes.
El usuario administrador confirma los datos creados/actualizados.
Caso de uso “Carga de problemas”
El usuario de control de calidad elige un proyecto y luego un modulo dentro del
proyecto.
El usuario de control de calidad selecciona su nombre para indicar que el fue quien
reporto.
El usuario de control de calidad ingresa una descripción del problema.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 108
Caso de uso “Modificación de problemas”
El usuario de control de calidad escoge de la página general de los problemas el
problema a modificar.
El usuario de control de calidad modifica el problema:
El usuario de control de calidad cambia el estado del problema.
El usuario de control de calidad cambia la descripción del problema.
El usuario de control de calidad confirma los datos creados/actualizados.
Caso de uso “generación de métricas”
El usuario elige un proyecto.
El usuario elige una métrica.
El usuario genera la métrica.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 109
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 110
“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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 111
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 112
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 113
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 114
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 115
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 116
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 117
[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/
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 118
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?
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 119
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 120
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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 121
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,
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 122
¿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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 123
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 124
¿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
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 125
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.
Plataformas de desarrollo de aplicaciones Web orientadas a componentes reutilizables
Ignacio Blanco Gustavo López 126
• 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.