Blanco Tesisingenieriainformatica

Tesis

Ingeniería en Informática

Plataformas de desarrollo de

aplicaciones Web orientadas a

componentes reutilizables

Alumno: Ignacio Carlos Blanco ([email protected])

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



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



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



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.



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.



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



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



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.



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



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.



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.



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



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.



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



.NET

.NET Framework

Mono

PHP

Prado

CakePHP

Ruby

Ruby on Rails



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.



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



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



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



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



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



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.



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



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.



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



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.



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?



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.



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.



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



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



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>



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.



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.


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



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



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.



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



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.



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>



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



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.


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



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.


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



• Manejo de eventos



• 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



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



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



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.


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



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.


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



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



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



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.

-



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 +



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.

-



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.

+



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



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



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




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




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



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




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.

-



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,

+



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.

-



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



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.



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




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:


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



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.



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:



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.



• 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



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



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

selección).

mail

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

reports

Provee una abstracción para reportes realizados con JasperReports así como también

para la exportación de los reportes a formatos varios (PDF, HTML, XLS).

context

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

del usuario actual.

security

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

autenticación basada en roles y perfiles.

writers

Implementación de writers utilizados para generar código HTML a ser utilizado por los

componentes provistos y también aquellos implementados por los usuarios del mismo.

utils

Clases utilitarias varias, incluye soporte para fechas, cadenas de caracteres, colecciones

y renderización.

test

Código necesario para realizar pruebas del framework.



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.



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



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.



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


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:


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


QNavigation.startPage("ComponentShowCase2", new Model(), new QFinalizeAction() {


//hago algo en caso de retornar con exito

}}, new QFinalizeAction() {


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



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

}





Figura 16: Ejemplo de acciones

Ejemplo de múltiples combos

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


QCF.comboSelector(form, "cmb1", "pais", "paises", "").setOnChangeListener(new QMethodListener(this, "onPaisChange"));

QCF.comboSelector(form, "cmb2", "ciudad", "ciudades", "").setHasNullElement(false).setVisible(paisSelected);

}





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



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



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:


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

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



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

QCF.checkBox(form, "chkOpcion1", "opcion1");




QCF.action(form, "btnBoton1", "onBoton1");




}

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;


QTextField txtBusqueda = QCF.textField(form, "txtBusqueda", "busqueda");

lblBuscado = QCF.messageLabel(form, "lblBuscado", "buscado");

lblBuscado.setInternationalize(false);



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



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



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



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

configuraciones como la siguiente:


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

QGroup group2 = QCF.group(group1, "grp2");

QFieldSet fds1 = QCF.fieldSet(group2, "fds1");

}



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



Figura 26: Ejemplo Validation scope 1

Allí se cargan los datos:


Se presiona “Guardar dirección”:


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




Vemos el código:



QCF.textField(group1, "txtNombre", "nombre").addValidator(QRequiredValidator.getInstance());


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


direccion = (Direccion) result;

}

}, QNullFinalizeAction.getInstance());

}

}

Ahora se ve el ejemplo donde se valida el campo nombre






QCF.textField(group1, "txtNombre", "nombre").addValidator(QRequiredValidator.getInstance());


QCF.textField(group2, "txtDireccion", "direccion").setEnabled(QDummyPredicate.FALSE);

QCF.action(group2, "btnDireccion", "onDireccion").setValidationScope(group1);

}

Group

Componente Código

QGroup



QCF.group(form, "grp”);

QGroup QuickTime and a

TIFF (Uncompressed) decompressorare needed to see this picture.

Fieldset

Componente Código

QFieldSet



QCF.fieldSet(form, "fds”);

Actions

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



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.



Figura 31: Jerarquía de acciones

Componente Código

QAction QuickTime™ and aTIFF (Uncompressed) decompressor


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


QCF.imageAction(form, "btnAccept", "onImage", img);

QLinkSubmit QuickTime™ and aTIFF (Uncompressed) decompressor


QCF.linkSubmit (form, "btnEnabled", "onEnabled");

QImageLinkSubmit QuickTime™ and aTIFF (Uncompressed) decompressor


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



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

datos presentes en el modelo del servidor.

Figura 32: Jerarquía de controles de entrada

Componente Código

QDatePicker



QCF.datePicker(form, "dtpDate", "date");

QTextField QuickTime and a


QCF.textField(form, "txtCountry",

"country");

QTextField QuickTime and a


QCF.textField(form, "txtCountry",

"country")

.setEnabled(QDummyPredicate.FALSE);

QComboSelector



QCF.comboSelector(form,

"cmbCountry", "country",

"countries", "");



QComboSelector



QCF.comboSelector(form, "cmbCountry", "country", "countries", ""). setHasNullElement(false);

QRadioSelector



QCF.radioSelector(form, "cmbCountry", "country", "countries", "");

QRadioSelector



QCF.radioSelector(form, "cmbCountry", "country", "countries", "").setHasNullElement(false);

QTextArea QuickTime™ and a


QCF.textArea(form, "txtComments", "comments");

QTextArea QuickTime™ and aTIFF (Uncompressed) decompressor


QCF.textArea(form, "txtComments", "comments").setEnabled(QDummyPredicate.FALSE);

QCheckBox QuickTime™ and aTIFF (Uncompressed) decompressor


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



QCF.palette(form, "palCountries", "countries", "countriesSelected", "");



Menú

Componente Código

QMenu

QMenuBar

QSimpleMenuItem



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.



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



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:



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:



Figura 35: Componente tabla con campos editables

El código para conseguir esto es:


grd.addTextBoxColumn("name", "name", false);






Otra funcionalidad destacada del componente Table es la selección de filas que permite

mostrar una grilla seleccionable:



Figura 36: Componente tabla con campos seleccionables

El código del ejemplo anterior es:


grd.setMultipleSelection("selectedCountries");





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

componente Table:



Figura 37: Componente tabla con paginación

El código es:


grd.setMultipleSelection("selectedCountries");





grd.getPaging().setPageSize(2);



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:



Figura 38: Diagrama de secuencia del modelo



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



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:



Figura 40: Front Controller

MVC


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



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



Template View


Descripción: El problema que presentan las páginas Web dinámicas, aquellas que toman

resultados de queries a base de datos y luego se agregan al HTML, es que estas páginas

se ven distintas con cada resultado.

La mejor manera de realizar este trabajo es creando páginas Web estáticas pero

colocando marcadores o placeholders que pueden ser procesados para colocar en esa

posición la información dinámica. Como la parte estática actúa como un template para

una respuesta en particular, se conoce a este patrón como Template View.

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:



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,



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



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



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



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



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.



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.



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:



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.



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”



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.



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.



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.



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



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



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



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



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



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.



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.



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



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?



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



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



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



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.




¿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



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.


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



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



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.


¿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



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.




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


planteado?

En términos generales WebWork encaja mejor en equipos pequeños que quieren ensuciar



sus manos y conocer mucho sobres las herramientas opensource que usan. No es ideal

para programadores que prefieren un desarrollo basado en drag&drop.

WebWork recompensa a los usuarios que se toman tiempo para aprender del framework.

Por ejemplo, aquellos que conocen los pros y contras (y han leído la documentación)

pueden sencillamente crear un ActionMapper que soporte “convención” antes que

“configuración”, pudiendo hacer que URLs como:

“/project/123/suite/456/test/create” se mapee a

“com.autogenerated.actions.projects.suite.test.CreateAction” y automáticamente pase en

los parámetros projectId = 123 y suiteId = 456. Los resultados serían “[action].jsp” o

“[action]-[result].jsp” o puede ser definido usando annotations.

El punto es que WebWork es mejor cuando es utilizado como base para un framework

relacionado directamente con la aplicación en cuestión.

Por otro lado WebWork debe ser tomado en cuenta cuando se desarrolla sobre

arquitecturas orientadas a componentes extensibles e interconectables, ejemplos de esto

son JIRA, Confluence o Jive. Esto es así debido al amplio soporte de lenguajes de

templating como es Velocity, así como también soporte para tags

¿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



En Struts 2.0 (Struts + WebWork) se espera:

• Mejor documentación.



• Soporte para estándares (OGNL).

• Soporte para AJAX (más widgets).


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

Blanco Tesisingenieriainformatica

Documents

Transcript of Blanco Tesisingenieriainformatica