martes, 1 de junio de 2010
Jboss Seam: "propagation=none" en <s:link> o <s:button>
Si tenemos una conversación activa y pulsamos sobre un enlace que posea el atributo "propagation=none", esto provocará que se abandone (es equivalente a Conversation.instance().leave()) la conversación actual y aquellas anidadas que posea o la anidada en la que estemos y su padre. Si otra vez accedemos a la misma página, se creará una nueva conversación. Si en nuestra aplicación ejecutamos cualquier acción que termine una conversación y existen conversaciones abandonadas, éstas también serán destruidas.
martes, 22 de septiembre de 2009
Manejo de peticiones en Wicket
Cuando Wicket determina que debe manejar una petición, delega su procesamiento a un objeto de tipo RequestCycle. El procesaminto se realiza en 4 pasos consecutivos que se muestran en la siguiente figura (hacer click en la imagen para ver con más claridad):
La gestión de URLs en Wicket es flexible, y en ocasiones, el mismo tipo de petición puede ser codificada de múltiples maneras. Por ejemplo, dependiendo de la configuración, los fragmentos de URL foo=bar, foo/bar y x773s=09is7 pueden significar lo mismo. En el primer paso del manejo de una petición, Wicket decodifica (desempaqueta los valores codificados) la URL de la petición sin importar la forma que tenga, Wicket lo interpreta de una única manera. El resultado de la decodificación es almacenado en un objeto de tipo RequestParameter.
Si observas los valores decodificados del objeto RequestParameter de la figura, puedes suponer qué hace la petición. La ruta de componente 2:actionLink hace referencia al componente con la ruta actionLink, que se encuentra en la página que Wicket conoce mediante el identificador 2. Wicket asigna números de versión cuando se producen cambios estructurales en las instancias de las páginas (por ejemplo, cuando se reemplazan, ocultan o se muestran componentes). En este caso, la versión de la página derivada de la decodificación de la URL es 0, lo que significa que nos encontramos ante la primera (sin modificar) instancia de la página.
En el siguiente paso, Wicket determina el RequestTarget. Wicket puede manejar diferentes tipos de peticiones -por ejemplo, páginas referenciables (el término en inglés es bookmarkable, es decir, páginas a las que podemos acceder poniendo la URL en el navegador), recursos compartidos, y peticiones AJAX. En la figura, la RequestTarget es una instancia de la clase ListenerInterfaceRequestTarget que encapsula la llamada a un enlace (interfaz ILinkListener) de una página previamente renderizada. En este caso, se obtiene la página previamente renderizada usando el identificador 2 y la versión 0, como puedes ver.
El tercer paso, procesamiento de los eventos, es opcional. Se usa para cosas como llamadas a enlaces o a comportamientos Ajax (los componentes en Wicket se pueden extender agregándoles comportamientos), pero no para páginas referenciables o para recursos compartidos. Durante el procesamiento de los eventos, la petición objetivo puede cambiar. Por ejemplo, esto puede ocurrir cuendo se llama a setResponsePage en el método onSubmit de un formulario, en cuyo caso una instancia de PageRequestTarget se usa para el resto del procesamiento de la petición. Llamando a setResponsePage es como más fácilmente se puede navegar de una página a otra cuando se manejan eventos como onClick u onSubmit.
El paso final es responder al cliente. Como ya se ha mencionado, el procesamiento final de una petición se delega al RequestTarget, que es el encargado de crear la respuesta. Un PageRequestTarget se ocupa de renderizar una página y enviarlar al cliente, un ShareResourceRequestTarget se encarga de localizar un recurso (un imagen por ejemplo) y enviarla al cliente, y un AjaxRequestTarget se encarga de renderizar componentes individuales y generar una respuesta XML que la librería Ajax del cliente pueda interpretar
La gestión de URLs en Wicket es flexible, y en ocasiones, el mismo tipo de petición puede ser codificada de múltiples maneras. Por ejemplo, dependiendo de la configuración, los fragmentos de URL foo=bar, foo/bar y x773s=09is7 pueden significar lo mismo. En el primer paso del manejo de una petición, Wicket decodifica (desempaqueta los valores codificados) la URL de la petición sin importar la forma que tenga, Wicket lo interpreta de una única manera. El resultado de la decodificación es almacenado en un objeto de tipo RequestParameter.
Si observas los valores decodificados del objeto RequestParameter de la figura, puedes suponer qué hace la petición. La ruta de componente 2:actionLink hace referencia al componente con la ruta actionLink, que se encuentra en la página que Wicket conoce mediante el identificador 2. Wicket asigna números de versión cuando se producen cambios estructurales en las instancias de las páginas (por ejemplo, cuando se reemplazan, ocultan o se muestran componentes). En este caso, la versión de la página derivada de la decodificación de la URL es 0, lo que significa que nos encontramos ante la primera (sin modificar) instancia de la página.
En el siguiente paso, Wicket determina el RequestTarget. Wicket puede manejar diferentes tipos de peticiones -por ejemplo, páginas referenciables (el término en inglés es bookmarkable, es decir, páginas a las que podemos acceder poniendo la URL en el navegador), recursos compartidos, y peticiones AJAX. En la figura, la RequestTarget es una instancia de la clase ListenerInterfaceRequestTarget que encapsula la llamada a un enlace (interfaz ILinkListener) de una página previamente renderizada. En este caso, se obtiene la página previamente renderizada usando el identificador 2 y la versión 0, como puedes ver.
El tercer paso, procesamiento de los eventos, es opcional. Se usa para cosas como llamadas a enlaces o a comportamientos Ajax (los componentes en Wicket se pueden extender agregándoles comportamientos), pero no para páginas referenciables o para recursos compartidos. Durante el procesamiento de los eventos, la petición objetivo puede cambiar. Por ejemplo, esto puede ocurrir cuendo se llama a setResponsePage en el método onSubmit de un formulario, en cuyo caso una instancia de PageRequestTarget se usa para el resto del procesamiento de la petición. Llamando a setResponsePage es como más fácilmente se puede navegar de una página a otra cuando se manejan eventos como onClick u onSubmit.
El paso final es responder al cliente. Como ya se ha mencionado, el procesamiento final de una petición se delega al RequestTarget, que es el encargado de crear la respuesta. Un PageRequestTarget se ocupa de renderizar una página y enviarlar al cliente, un ShareResourceRequestTarget se encarga de localizar un recurso (un imagen por ejemplo) y enviarla al cliente, y un AjaxRequestTarget se encarga de renderizar componentes individuales y generar una respuesta XML que la librería Ajax del cliente pueda interpretar
domingo, 20 de septiembre de 2009
Crear un proyecto Wicket
En el siguiente enlace tenemos una utilidad que nos genera el comando para crear un proyecto Wicket con Maven, sólo tendremos que indicar groupId y artifactId de un proyecto con Maven.
Crear un proyecto Tapestry 5 con Maven
1) Hay que ejecutar el siguiente comando:
mvn archetype:generate -DarchetypeCatalog=http://tapestry.formos.com/maven-repository
mvn archetype:generate -DarchetypeCatalog=http://tapestry.formos.com/maven-repository
Al ejecutar este comando en consola, nos pedirá los siguientes parámetros:
- groupId
- artifactId
- version
- package
Para preparar el proyecto para Eclipse nos introduciremos en la carpeta del proyecto y ejecutaremos el siguiente comando:
mvn eclipse:eclipse -DdownloadSources=true -DdownloadJavadocs=true
Ya sólo queda copiar la carpeta creada a nuestra carpeta de proyectos de Eclipse y crear un nuevo proyecto java en eclipse con el mismo nombre. Después de crearlo tendremos que habilitar Maven para el nuevo proyecto.
Para más información visitar el siguiente enlace.
martes, 5 de mayo de 2009
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 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:
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
- 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.
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)
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 |
Suscribirse a:
Entradas (Atom)