Ciclo de Vida en JSF

    Hay que tener en cuenta que en la web existen discursos mucho más completos y mejores acerca de este tema, pero la idea es que éste resulte “coloquial” a los desarrolladores.    El diagrama que representa el ciclo es el siguiente, desde un punto de vista funcional y adaptado a una terminología sencilla:

  A continuación se describe este procedimiento siguiendo el orden numérico de las distintas fases y los posibles caminos alternativos:

---

    La primera fase puede denominarse como “Aplicar los valores de la petición” (ver recuadro 1). En ella se van recorriendo todos los componentes del formulario siguiendo la jerarquía padre-hijo al mismo tiempo que se recuperan sus valores a partir de los parámetros de la petición o request enviada al servidor. El valor se asigna a cada componente en su propiedad submittedValue.
    Esto ocurre siempre excepto en dos casos: si el componente está deshabilitado (disabled = true) o si posee una condición que indica cuándo debe pintarse en pantalla(atributo ‘rendered’).
    A continuación tendrá lugar bien la fase de validaciones o bien la ejecución de cada uno de sus eventos asociados dependiendo del valor del atributo ‘immediate’ de los componentes de la página (ver al final el apartado “Uso del atributo ‘immediate’.”).

---

    Siguiendo la secuencia normal del ciclo, la siguiente fase que tiene lugar es la de “Procesamiento de las validaciones” (ver recuadro 2). Este proceso consiste en la validación del dato suministrado por el usuario en función de las reglas de validación definidas para el componente.
    Es común el uso de un validator o un converter, que se aplica sobre el submittedValue. Si no se produce ningún error de validación o de conversión, el valor del submittedValue de cada componente válido pasa a ser null y entonces se almacena en su ‘value’ el dato convertido al tipo que tenga la propiedad del bean a la que se asignará posteriormente.
    En caso contrario, el ciclo de vida avanza directamente hasta la fase de presentación de la respuesta.

---

    Durante la fase de “Proceso de Eventos”  (ver recuadro 3) se llevan a cabo todos los eventos asociados a las acciones realizadas por el usuario.

---

    Pasamos a la próxima fase del ciclo: “Actualización de los valores del Modelo” (ver recuadro 4). Tras las validaciones y/o ejecución de los eventos tiene lugar la asignación del ‘value’ de los componentes a los atributos del bean.

---

    Entonces llegamos a la fase conocida como “Invocar la aplicación” (ver recuadro 5) en la que se usan los valores del bean para ejecutar la lógica de negocio y se llevan a cabo las operaciones correspondientes a las acciones del usuario.

---

    Por último, tiene lugar la fase: “Presentación de la respuesta” (ver recuadro 6).  La implementación de JavaServer Faces delega su autoridad en el contenedor JSP para enseñar la página que el usuario ve por pantalla, y donde todos los campos están informados con su valor en ese momento.
    Si se produjo un error en la fase de validación, se muestra la response (pantalla de respuesta) con los valores que introdujo el usuario y además un mensaje informativo del error. El valor que aparecerá en pantalla para cada componente de la página será el primero no nulo que el servidor encuentre en la secuencia:

Componente.submittedValue –> Componente.value –> Bean.attribute

 

Uso del atributo ‘immediate’

    El atributo ‘immediate’ de los componentes de un formulario está presente en la mayoría de las fases del ciclo de vida.
    Ya en la primera fase del ciclo se comprueba el valor de dicho atributo. Si vale true, el ciclo avanza hasta la tercera fase, saltándose las validaciones pertinentes. En caso contrario, se continúa el ciclo normal hacia la fase 2.
    Es importante señalar en este punto que si ‘immediate’ no se indica su valor es false, ya que así está definido en la declaración de atributos de JSF. Y además es importante saber que el hecho de asignarle el valor true  implica no tener acceso a los valores de los campos del formulario así como a los errores que se hubieran producido.

Glosario

Componente: elemento que forma parte del formulario y provee funcionalidades para interactuar con el usuario. Puede ser de diferentes tipos (caja de texto, botón, control de selección…) y el usuario “completa” el formulario a través de su modificación.

Converter: se utiliza cuando es necesario convertir el dato introducido por el usuario al tipo apropiado. Por ello hay que indicar como nombre el de una clase bean que implemente la interfaz Converter.

Evento: acción que queremos que se produzca al cambiar el valor del componente. Por ejemplo, el caso de un selectOneMenu cuando cambiamos la opción marcada del menú desplegable. Solemos indicar estas acción a través de los atributos ‘onchange’, ‘onblur’, ‘onclick’, etc. en el código jsp.

Evento de acción: acción declarada en el atributo ‘action’ de un componente. A cada botón que exista en una página le corresponde una acción (no necesariamente distinta a las demás), y que nosotros solemos denominar con los nombres “doXxxAction” o “goXxxAction”. Por ejemplo: doActualizarAction(), goAtrasAction().

Nota: JSF entiende ‘evento’ como cualquier acción realizada por el usuario. Por ejemplo: pulsar en un botón, hacer clic sobre un link, escribir en un inputText, etc. Como se lee un poco más arriba, nosotros distinguimos entre ‘eventos’ propiamente dichos, y ‘eventos de acción’.

SubmittedValue: valor introducido por el usuario en el formulario.

Validator: responsable de asegurar que el valor ingresado por un usuario es aceptable. Uno o más validadores pueden ser asociados con un solo componente y se definen en clases Java independientes.

Referencias

• Documentación Oracle JDeveloper
• Tutorial J2EE
• IBM: JSF for Nonbelievers

Mi agradecimiento a Inma Molina por la edición de este artículo y el diseño de la imagen.

JSF Spring Hibernate

Una arquitectura muy extendida para aplicaciones web en JAVA, es la basada en JSF, Spring e Hibernate. La intención principal es que pueda servir como idea general para otros proyectos, pero aprovecharé para comentar las ventajas que ofrecen y los problemas que nos hemos encontrado.

Capa de presentación.

JSF: Estándar de Sun para simplificar el desarrollo de interfaces de usuario en aplicaciones web. En particular hemos elegido la implementación de MyFaces y la librería de tags JSF Tomahawk.

JasperReports: Para la generación de reports.

Dozer: Con este tipo de  arquitecturas se suele usar BeanUtils y código Java para mapear los Objetos de Hibernate y los Backing-beans de JSF. Nosotros hemos seleccionado Dozer para sustituir a BeanUtils.

Capa de lógica de Negocio.

Spring: Framework a nivel de aplicación. Se encarga del control de la transacción y mediante configuración proporciona a los POJOS todo lo que necesiten para ejecutar la lógica.

POJOS: Conteniendo la lógica de negocio y nada más.

Capa de datos.

Hibernate: Motor de persistencia.

DAOS:   Código generado para el acceso a los datos

POJOS: O beans, representación java de la estructura de la base de datos. También se trata de código generado.

Ventajas, inconvenientes y soluciones aplicadas.

Esta arquitectura está basada en estándares y soluciones probadas de alto reconocimiento. No necesita de servidores de aplicaciones de alto coste económico y si ya se tienen funciona perfectamente en ellos. Esta arquitectura, junto con la instrucción técnica necesaria ofrece al programador una clara división de capas y funciones que debe realizar en cada capa. Facilita el mantenimiento de la aplicación y es por eso que se recomienda para proyectos de gran tamaño y/o larga vida. Reduce el código repetitivo. Control de transacción, creación de DAOS, … La arquitectura en si misma, fuerza o al menos orienta al uso de determinadas buenas prácticas. El esfuerzo requerido para la documentación, definición de plantillas y tutoriales paso a paso, también ha redundado en un mayor rendimiento y en la automatización de ciertas tareas repetitivas. Por ejemplo el desarrollador de los informes sólo se tiene que preocupar de la presentación del mismo ya que todo el código necesario es generado con Velocity. 

Curva de aprendizaje larga. De la manera en la que trabajamos la curva de aprendizaje podríamos decir que es media para los desarrolladores puesto que realmente sólo tienen que aprender realmente JSF, ya que de Spring sólo se ha de entender la filosofía y de Hibernate además de la filosofía DAO, la API relacionada con las consultas. Para facilitar el aprendizaje de JSF se han realizado documentos enfocados al proyecto indicando el uso que se hace de cada tag.

También se han creado plantillas de cada uno de los archivos y se han documentado tutoriales “paso a paso” para un mantenimiento sencillo y para un mantenimiento con maestro-detalle.

Para más información sobre el tiempo dedicado al desarrollo ver apartado Tiempos.

La definición de los ficheros de hibernate es compleja y requiere el conocimiento de qué es lo que se va a necesitar, cómo y cuando. Una mala configuración puede acarrear problemas de rendimiento o un cambio en la configuración puede hacer que fallen otros desarrollos. Para crear la versión inicial se usa el generador de hibernate facilitando así el trabajo. El analista-programador que ha diseñado el caso de uso y sabe lo que se va a necesitar es quien configura los archivos, es el responsable de los mismos y el que se encarga de los posibles cambios que necesiten teniendo en cuenta su conocimiento global del proyecto.

En función de la aplicación puede convertirse en un “matar moscas a cañonazos”. Es evidente que esto puede pasar. Esta arquitectura es de tipo “general”, permite realizar “cualquier cosa”, si sólo se necesita mantener cierta información de la base de datos, apenas hay lógica de negocio, o la lógica de negocio se implementa en la base de datos y en muchos otros casos no es necesaria este tipo de arquitectura.

Tiempos

Un informe consiste en una pantalla de filtro para el usuario y un listado en PDF con los elementos que cumplen el filtro. El tiempo dedicado a cada uno de ellos se estimó inicialmente en 8 horas, pero se ha reducido el tiempo dedicado a menos de dos en la mayoría de los casos gracias a la generación de código.

Un mantenimiento simple consiste en una pantalla de filtro para el usuario, un listado paginado y las opciones de nuevo, editar y eliminar. El tiempo estimado para el desarrollo es de 8 horas, pero en la mayoría de los casos se acaban antes de que acabe el día con todas las pruebas pertinentes realizadas.

Un mantenimiento medio es aquél mantenimiento simple que mantiene más de una tabla o tiene muchos campos a mantener. El tiempo estimado en este caso es de 24 horas aunque algunos casos se ha bajado de 10.

Un mantenimiento complejo es aquél mantenimiento con maestro-detalle y muchos campos a mantener. En este caso la estimación es de 40 horas y en los resultados obtenidos hay grandes diferencias que asociamos a la complejidad de la presentación cuando hay muchos campos y a que no hay un grupo de mantenimientos muy complejos.

 Ventajas e inconvenientes de cada componente de la arquitectura

JSF

Realmente simplifica el desarrollo de interfaces de usuario. En muchos aspectos es incluso más natural que Struts.Tienes control sobre algunos eventos.Los componentes pueden ser muy potentes, incluso encapsulando sus propios archivos css y js.Muy configurable. Por ejemplo se puede tener acceso declarativo a los beans de Spring. O un caso más sencillo modificar la presentación en pantalla de los datos mediante converters.   No tiene un control global de excepciones. Cada método de cada Backing-Bean ha de controlar y tratar las excepciones. Tiene un ciclo de vida complejo para poder gestionar los eventos. Hay que tener muy claro que si el Backing-Bean está en scope request algunas cosas no funcionan como uno espera. Las validaciones son por componente no por formulario, haciendo difícil las validaciones basadas en otros componentes. Como efecto secundario la lógica de negocio de las consultas es llamada dos veces, la primera vez con el filtro anterior y la segunda vez con el nuevo filtro introducido por el usuario.No está pensado para el desarrollo de pruebas en muchos aspectos, aunque comparado con struts 1.0, JSF es la panacea.La extensión de sus componentes y el desarrollo de nuevos componentes requieren un buen conocimiento del ciclo de vida de los componentes.Hay claras limitaciones en el uso de librerías de Tags JSF de diferentes proveedores.  

Tomahawk

Componentes básicos extendidos para aumentar sus prestaciones. Ej. El tag panel puede deshabilitar todos los inputs que contiene, facilitando mucho el desarrollo de las pantallas de consulta y edición.Nuevos componentes muy útiles. Tablas autoordenables, paginación, menú, campos fecha,… No se pueden mezclar librerías de Tags JSF de otros proveedores. 

JasperReports

Se integra perfectamente con la arquitectura permitiendo reutilizar la lógica de negocio desarrollada. Es menos eficiente que usar Oracle Reports para hacer los listados, pero esto exige que se duplique la lógica de obtención del listado. 

Dozer

Simple,  configurable mediante XML y realiza automáticamente conversiones de tipos.Una sola línea de código para realizar el mapeo y el resto en XML.  Se ha de tener cuidado con lo que mapeas y con los nombres de las funciones que no sean getter/setter. 

Spring

Simple, entre comillas.Configurable mediante XML, de una manera anteriormente desconocida. Ligero.Realmente simplifica el desarrollo de la lógica de negocio, evitando que el programador se tenga que preocupar por cosas como la transacción.Realmente simplifica el desarrollo de pruebas de unidad. 

Hibernate

Prestaciones de rendimiento y fiabilidad.Buenos generadores de código. Integración con PL/SLQ es pobre pero te permite hacerlo.  

Referencias

Petstore. Desarrollado con JSF, Spring, Hibernate.

http://java.sys-con.com/read/46977.htm

JSF-Spring. http://jsf-spring.sourceforge.net/

Velocity. http://velocity.apache.org/engine/releases/velocity-1.5/overview.html