Fundeweb es un Framework de desarrollo basado en tecnologías J2EE y desarrollado mediante el IDE eclipse. El grupo de Metodologías, Normalización y Calidad del Software (MNCS) desarrolla, mantiene, da soporte y evoluciona dicho framework. A su vez define una serie de normativas para el correcto desarrollo y facilitar la coordinación de equipos de trabajo y cambios de proyecto.
Existen dos versiones del Framework: Fundeweb 1 y Fundeweb 2, siendo ésta última sobre la cual se desarrollan los nuevos proyectos, la versión 1 se mantiene para dar soporte a proyectos antiguos que aún no se han podido actualizar a la pila tecnológica de Fundeweb. Junto con la instalación del entorno se incluyen una serie de librerías de utilidades gestionadas por MNCS y un arquetipo para la creación de nuevos proyectos.
Un arquetipo es la semilla de todo proyecto Fundeweb, el cual nos proporcionará la estructura de nuestro el proyecto junto con todas las librerías necesarias para su desarrollo. Una vez creado un proyecto sólo tendremos que configurar unos pocos aspectos, como la base de datos a utilizar o si quiero o no incorporar autenticación para empezar a trabajar. Este arquetipo incluye por defecto:
La arquitectura se basa en la pila tecnológica J2EE añadiendo otras librerías de terceros que enriquecen las posibilidades del Framework de cara a facilitar los desarrollos y mantener lo más actualizado posible todo el ecosistema que se utiliza.
Partiendo desde el punto de vista de un usuario común, la aplicación web es sólo un conjunto de pantallas que hacen una determinada tarea, pero no sabe todo lo que sucede sin que se dé cuenta desde que hace click con el ratón hasta que obtiene el resultado. Nuestra labor es conocer en qué puntos entran en acción cada tecnología de la pila del Framework para que podamos mejorar y optimizar nuestro código en cada momento, previniendo a su vez problemas de seguridad.
En la imagen anterior está enumerado el orden del flujo que se realiza desde el click del usuario hasta la obtención de la respuesta:
Primefaces: Actúa ejecutando las acciones javascript asociadas al componente accionado. Dichas acciones pueden ser desde efectos visuales hasta validación de datos, también lanza el submit del formulario en el que nos encontramos o una llamada AJAX.
JSF: Examina el árbol DOM y la acción realizada y comienza la ejecución de su ciclo de vida en caso de detectarse un “Submit”, bien sea del formulario entero, bien sea parcial (AJAX).
Seam: Intercepta y gestiona los eventos y contenidos enviados por JSF para dotar a la lógica de la aplicación de los elementos necesarios para gestionar y controlar la acción realizada por el usuario. (Se ejecutará la lógica de la aplicación).
Hibernate: Será el encargado final de persistir, actualizar o eliminar los datos que así lo necesiten de base de datos.
Seam: Decide, tras ejecutar la lógica de negocio, hacia dónde debe navegar la aplicación.
JSF: Finaliza la ejecución de su ciclo de vida preparando y renderizando la página destino a la que se ha navegado.
Primefaces: Dibuja los componentes y ejecuta las acciones javascript pertinentes.
Este ejemplo es muy resumido pero debemos entender en qué punto interviene cada tecnología para poder localizar errores y saber depurar correctamente la aplicación. Cabe destacar que también debemos conocer el ciclo de vida de JSF ya que es el orquestador de todo el proceso apoyándose principalmente en Seam.
El ciclo de vida de JSF es lo que marca qué ocurre desde que el usuario hace click hasta que se devuelve una respuesta. El resto de tecnologías se incorporan a este ciclo de vida enriqueciendo algunas de las etapas, pero el flujo siempre lo marcará JSF
En el dibujo anterior podemos seguir lo que ocurre internamente y los posibles flujos que puede recorrer el proceso hasta que se le da la respuesta al usuario final.
Fase 1: Reconstrucción del árbol de procesamiento
Tras un submit se restaura el árbol de contenido.
El controlador examina el contenido y crea los componentes que se requieran por el contenido recibido.
El controlador examina el contenido recibido para saber si es una nueva vista o está en una ya creada de antemano.
El controlador almacena los ID de las vistas que ha recibido para saber qué objetos debe inicializar y cuales recargar.
Fase 2: Aplicación de los valores reconstruidos en el servidor
Cada componente creado en el paso anterior obtiene su valor en base a lo recibido en el paso anterior.
Los valores recibidos se convierten a los esperados por sus respectivos componentes.
Si un componente es marcado como inmediato, se asigna el valor y se pasa a la etapa de validación antes de tratar el resto de componentes.
Fase 3: Procesamiento de eventos
En este punto han podido lanzarse errores de conversión de tipos o de validación en caso de valores inmediatos.
Estos eventos se capturan y se le indican al controlador.
El controlador redirigirá el flujo hacia un estado seguro devolviendo un evento de error en caso de proceder.
Fase 4: Validación de valores introducidos
Se procede a comprobar si los valores introducidos cumplen las restricciones definidas.
Estos eventos se capturan y se le indican al controlador.
El controlador redirigirá el flujo hacia un estado seguro devolviendo un evento de error en caso de proceder.
Se ejecutarán los validadores estándar y los definidos por el usuario en el código fuente.
En caso de no cumplirse alguna restricción se lanzará un evento de error y se redirigirá el flujo.
Fase 5: Actualización del modelo
Una vez validados los datos se procede a actualizar el modelo.
Se copian los datos procesados en las clases Java que los representa pasando la información a la parte de control de la aplicación.
En este punto los valores copiados son válidos desde el punto de vista de la corrección, aunque pueden ser inválidos para la lógica de negocio.
Fase 6: Invocar aplicación
Con los valores introducidos procedemos a invocar a la lógica de negocio de la aplicación.
Tras procesar los datos pasaremos a generar una respuesta o bien a un estado de error.
En este punto se persistirán los datos, calculará la redirección, se harán las llamadas a servicios externos, etc.
Fase 7: Renderizado de la respuesta al cliente
Se genera la página de respuesta al cliente en base al resultado obtenido en la fase anterior.
Se tratará el árbol de respuesta para mostrar los elementos que así sean necesarios como s