Modelo contextula de componentes en Seam

Jboss-Seam se apoya en este modelo para gestionar los componentes (clases) que forman parte de una aplicación seam. Dicho modelo se puede explicar de la siguiente manera:

• Seam es una factoría que crea objetos (instancias) según la definición del componente (clase).
• Después de la creación, cada objeto es almacenado en un contenedor bajo uno de los varios contextos existentes, con distintos tiempos de vida, creando el contexto (scope) de los objetos y capaz de mantener el estado de cada uno.
• Seam promueve la interacción de estos objetos con estado a través de contextos, ensamblándolos (bijección de dependencias) acorde a los metadatos asociados a sus respectivas clases.

EXPLICACIÓN:

Seam actúa como un contenedor dividido en distintos compartimentos, en cada compartimento se almacenan una serie de componentes. Cada compartimento constituye lo que seam denomina contexto. Un contexto define qué componentes podemos encontrar en él y durante cuánto tiempo. Para ser más precisos, seam gestiona nombres de variables de contexto. Una variable de contexto no es más que una referencia a la instancia de un componente de seam.

¿QUÉ COMPONENTES GESTIONA SEAM Y QUÉ SON?

Jboss-Seam puede gestionar los siguientes componentes:

• EJB Stateful Bession Beans
• EJB Stateless Session Beans
• EJB Message Driven Beans
• JPA Entity Beans
• POJO (Plain Old Java Object)

Como podemos ver, un componente en seam no es más que una clase java que se define mediante una programación declarativa (anotaciones, XML), en dicha declaración definimos la variable que accede a una instancia de una clase y su alcance (contexto).

CONTEXTOS EN SEAM

Los contextos están ordenados de menor a mayor duración:

STATELESS

En este contexto no se almacenan las variables. Los componentes en este contexto se instancian cada vez que se resuelve su nombre.

EVENT

Es análogo al scope request de un servlet. La variable existe desde el comienzo de la fase Restore View hasta el final de la fase Render Response del ciclo de vida de una petición en JSF o hasta que se produce una redirección.

PAGE

Comienza al pricipio de la fase Render Response y continua con cada postback JSF hasta que se produce una redirección o se navega a una página distinta.

Aclaración: postback es una acción en una página web en la que se envía una página entera y su contenido al servidor para su procesamiento y éste devulve la misma página (un formulario de logueo por ejemplo). No se debe confundir con actualizar la página.

CONVERSATION

La variable existe desde el final de la fase Restore View hasta el final de la fase Render Response, incluso se se produce una redirección. Si se convierte en una conversación larga (long-running conversation) abarca múltiples peticiones de un mismo usuario hasta que se termina. Las conversaciones se propagan mediante el uso de parámetros especiales de petición para peticiones que no sean postback y a través del árbol de componentes JSF en el caso de peticiones postback.

SESSION

Es análogo al scope session de los servlets. Los accesos a componentes en este contexto son serializados.

APPLICATION

Análogo al scope application de los servlets

BUSINESS PROCESS

Abarca multiples conversaciones de múltiples usuarios. Este contexto se controla de manera declarativa mediante estados de inicio y fin en el fichero de definición del proceso de negocio.

UNSPECIFIED

Es una directiva que indica que el contexto debería ser implícito. Depende de las circunstancias, se le dice a seam para cualquier uso del contexto del componente actual o para ejecutar una búsqueda a través de todos los contextos de manera jerárquica.

CONTEXTOS POR DEFECTO DE LOS COMPONENTES

COMPONENTE	CONTEXTO
EJB Stateful Session Bean	Conversation
EJB Stateless Session Bean	Stateless
EJB Message Driven Bean	Stateless
JPA Entity Bean	Conversation
POJO	Event

Anotaciones para validar Beans en Seam

@Length(min=, max=) Comprueba que la longitud de una cadena se encuentra dentro de un rango
@Max(value=) Comprueba que un valor es menor o igual al indicado
@Min(value=) Comprueba que un valor es mayor o igual al indicado
@NotNull Comprueba que el valor no es nulo
@Past Comprueba que un objeto Date es anterior a la fecha actual
@Future Comprueba que un objeto Date es posterior a la fecha actual
@Pattern(regex=”regexp”, flag=) Comprueba que una cadena cumple el patrón indicado
@Range(min=, max=) Comprueba que un valor está entre el máximo y el mínimo indicado
@Size(min=, max=) En las colecciones, comprueba que el tamaño de la colección se encuentra entre los valores indicados
@AssertFalse Asume que el método devuelve false
@AssertTrue Asume que el método devuelve true
@Valid En coleccuiones o mapas comprueba que todos sus valores son válidos
@Email Comprueba que una cadena cumple con el formato de un e-mail

Cambiar puertos en Jboss 5

Para cambiar los distintos puertos que usa jboss 5 por defecto accedemos al fichero:

/jboss-5.x../server/default/conf/bootstrap/bindings.xml

En dicho fichero se pueden cambiar los puertos.

Formateo de fechas con DateFormat

DateFormat es una clase abstracta de la API estándar de Java que nos permite, entre otras cosas, pasar de objetos Date o Calendar a String con un formato determinado y realizar la operación inversa, crear objetos Calendar o Date a partir de una cadena que contiene la fecha.

De la esta clase hereda otra que realiza las operaciones de manera más sencilla: SimpleDateFormat. En el siguiente ejemplo se ha creado una clase llamada DateFormatter con dos métodos: uno para obtener un objeto Date a partir de un String y otro para realizar la operación inversa.

El patrón MVC

El patrón MVC (Model-View-Controller: Modelo-Vista-Controlador) es un patrón de arquitectura de software que separa el desarrollo de una aplicacíon en tres capas:

• Modelo: encapsula los datos de la aplicación y la lógica para interactuar con ellos.
• Vista: maneja la interacción con el usuario y la representación del modelo
• Controlador: Es el puente entre las dos capas anteriores, se encarga de seleccionar el modelo solicitado por el usuario y seleccionar la vista adecuada para representarlo.

El siguiente diagrama muestra una representación de dicho modelo:



Cada una de estas capas a su vez se puede implementar usando uno o varios patrones de diseño según las necesidades. En el siguiente enlace se muestra una breve explicación de los patrones de diseño más importantes para cada una de las capas.

PATRÓN FRONT CONTROLLER (CONTROLADOR FRONTAL):

Con él se pretende crear un armazón estandar para administrar solicitudes.

El ciclo vital de una solicitud a través de un controlador frontal sigue los siguientes pasos:

• El usuario emite una solicitud al controlador de la aplicación
• La solicitud se divide en parámetros de formulario
• La solicitud se autentifica
• La acción solicitada se mapea a un recurso específico
• Se crea un objeto de comandos para procesar la solicitud
• La solicitud se envía a la página adecuada
• La salida de la acción solicitada se muestra al usuario

ESTRATEGIAS:

1) AYUDA DE SOLICITUD: Esta estrategia implementa una clase que recibe como parámetro la solicitud y la procesa pudiendo realizar las funciones de autentificación de la solicitud (se comprueba que se ha recibido los parámetros esperados) y se mapea al objeto de comandos que realiza las operaciones solicitadas (nos devuelve el objeto Action).

2) CONTROLADOR Y COMANDO: Se crea un objeto comando que realiza las operaciones solicitadas. Nuestro objeto comando es el encargado de obtener el modelo, realizar las operaciones necesarias sobre el mismo y seleccionar la vista que va a representar el modelo.

PATRÓN DECORATING FILTER (FILTRO DECORADOR):

Este patrón nos permite modificar la solicitud antes de ser entregada al controlador correspondiente y modificar la respuesta antes de ser entregada al cliente. Entre los posibles usos de los filtros podemos destacar:

• Registrar información importante sobre cada solicitud
• Autentificar usuarios
• Transformar los datos de entrada antes del procesamiento
• Transformar los datos de la respuesta para un dispositivo específico
• Validar los datos del formulario e interrumpir el procesamiento si fuera necesario

PATRÓN VIEW HELPER (AYUDANTE DE VISTA):

Este patrón especifica que se utilicen helpers para adaptar los datos del modelo a la capa de presentación de una aplicación. Estos helpers consisten en librerías de etiquetas (creadas por el propio programador o utilizando etiquetas proporcionadas por algún framework) o JavaBeans o ambos.