Diferencia entre revisiones de «Inter Portlet Communication»
(→Client Side) |
|||
| Línea 1: | Línea 1: | ||
| − | Inter Portlet Communication o Comunicación Entre Portlets es la capacidad de los portlets | + | Inter Portlet Communication o Comunicación Entre Portlets es la capacidad de los portlets que comparten una misma página de comunicarse entre sí independientemente de que estén en el mismo módulo o incluso desarrollados con las mismas herramientas. |
La comunicación entre los portles puede ocurrir de tres maneras diferentes: | La comunicación entre los portles puede ocurrir de tres maneras diferentes: | ||
| Línea 9: | Línea 9: | ||
=== Server Side === | === Server Side === | ||
| − | En este caso la comunicación se produce enteramente del lado del servidor entre las fases de "Process Action" y "Render". Luego de iniciada la fase de Process Action los portlets pueden dejar información en un lugar común a todos los portlets administrado por el portal. Al entrar en la etapa de "Render" los portlets pueden utilizar esta información para | + | |
| + | En este caso la comunicación se produce enteramente del lado del servidor entre las fases de "Process Action" y "Render". Luego de iniciada la fase de Process Action los portlets pueden dejar información en un lugar común a todos los portlets administrado por el portal. Al entrar en la etapa de "Render" los portlets pueden utilizar esta información para mostrar diferente información. | ||
| + | |||
| + | Otra forma de comunicarlos del lado del servidor es que el portal invoque métodos de los portlets de destino de los mensajes antes de la fase de render. Esto posibilita que los portlets de destino de los mensajes puedan emitir nuevos mensajes para otros portlets. | ||
| + | |||
| + | Todos los mensajes deben quedar resueltos antes de iniciarse la fase de Render. | ||
| + | |||
=== Asynchronous Server Side === | === Asynchronous Server Side === | ||
| + | |||
Los portlets se comunican entre sí a través del servidor pero fuera del ciclo de Request-Response. Envían un pedido asincrónico (ej: Ajax)y producen un cambio. El portal debe comunicar ese cambio a los otros portles que deben estar haciendo una consulta periódica en forma asincrónica o utilizando alguna tecnología tipo COMET. | Los portlets se comunican entre sí a través del servidor pero fuera del ciclo de Request-Response. Envían un pedido asincrónico (ej: Ajax)y producen un cambio. El portal debe comunicar ese cambio a los otros portles que deben estar haciendo una consulta periódica en forma asincrónica o utilizando alguna tecnología tipo COMET. | ||
| Línea 18: | Línea 25: | ||
=== Client Side === | === Client Side === | ||
| + | |||
Esta es una comunicación "liviana" que no involucra comunicación con el servidor por lo que no cambia el estado del portlet ni cambia la información en el servidor. | Esta es una comunicación "liviana" que no involucra comunicación con el servidor por lo que no cambia el estado del portlet ni cambia la información en el servidor. | ||
Un ejemplo podría ser un portlet que sirve como "control remoto" de lo que se visualiza en otro. Al hacer click en un botón del control remoto puede esconderse o mostrarse una sección del otro portlet. | Un ejemplo podría ser un portlet que sirve como "control remoto" de lo que se visualiza en otro. Al hacer click en un botón del control remoto puede esconderse o mostrarse una sección del otro portlet. | ||
| Línea 24: | Línea 32: | ||
Una implementación típica es a través de llamadas de Javascript que se comunican a través del navegador como si fuese una única página en html. | Una implementación típica es a través de llamadas de Javascript que se comunican a través del navegador como si fuese una única página en html. | ||
| + | |||
| + | |||
== IPC en JSR 286 == | == IPC en JSR 286 == | ||
En la especificación 2.0 de Portlets se agregan dos formas de realizar IPC. Ambas son del lado del servidor y son las únicas formas estandarizadas de realizar IPC al momento de la release de la JSR 286. | En la especificación 2.0 de Portlets se agregan dos formas de realizar IPC. Ambas son del lado del servidor y son las únicas formas estandarizadas de realizar IPC al momento de la release de la JSR 286. | ||
| + | |||
| + | |||
=== Shared Render Parameters === | === Shared Render Parameters === | ||
| + | |||
| + | Esta forma de implementarlo es a través de poner disponible para los portles la posibilidad de hacer visibles para otros portles ciertos parámetros render.. | ||
| + | |||
=== Events === | === Events === | ||
| + | |||
| + | Para la versión 2.0 de la especificación de Portlets se agregó una nueva fase entre la de "Process Action" y "Render" llamada "Process Events" y se establece un mecanismo para que los portlets puedan publicar eventos y suscribirse a los mismos. | ||
| + | |||
| + | El encargado de recolectar los eventos publicados y redistribuirlos es el portal. | ||
| + | |||
| + | Los eventos pueden publicarse durante la fase de "Process Action" y "Process Events" permitiendo que durante el procesamiento de un evento se puedan publicar nuevos eventos. | ||
| + | |||
| + | Todos los eventos se procesarán antes de comenzar con la fase de "Render". | ||
| + | |||
| + | Los eventos se publican a través del método setEvent de la clase ActionResponse y pueden ser procesados tanto en el método processEvents de la interfaz Portlet o anotando métodos con la anotación @ProcessEvent y especificando a que evento responderá el método. Este último es preferible ya que evita tener que identificar que evento se produjo dentro del cuerpo del método. | ||
Revisión del 17:45 25 mar 2009
Inter Portlet Communication o Comunicación Entre Portlets es la capacidad de los portlets que comparten una misma página de comunicarse entre sí independientemente de que estén en el mismo módulo o incluso desarrollados con las mismas herramientas.
La comunicación entre los portles puede ocurrir de tres maneras diferentes:
- Server Side (del lado del servidor)
- Asynchronous Server Side (del lado del servidor en forma asincrónica)
- Client Side (del lado del cliente navegador)
Contenido
Server Side
En este caso la comunicación se produce enteramente del lado del servidor entre las fases de "Process Action" y "Render". Luego de iniciada la fase de Process Action los portlets pueden dejar información en un lugar común a todos los portlets administrado por el portal. Al entrar en la etapa de "Render" los portlets pueden utilizar esta información para mostrar diferente información.
Otra forma de comunicarlos del lado del servidor es que el portal invoque métodos de los portlets de destino de los mensajes antes de la fase de render. Esto posibilita que los portlets de destino de los mensajes puedan emitir nuevos mensajes para otros portlets.
Todos los mensajes deben quedar resueltos antes de iniciarse la fase de Render.
Asynchronous Server Side
Los portlets se comunican entre sí a través del servidor pero fuera del ciclo de Request-Response. Envían un pedido asincrónico (ej: Ajax)y producen un cambio. El portal debe comunicar ese cambio a los otros portles que deben estar haciendo una consulta periódica en forma asincrónica o utilizando alguna tecnología tipo COMET.
Client Side
Esta es una comunicación "liviana" que no involucra comunicación con el servidor por lo que no cambia el estado del portlet ni cambia la información en el servidor. Un ejemplo podría ser un portlet que sirve como "control remoto" de lo que se visualiza en otro. Al hacer click en un botón del control remoto puede esconderse o mostrarse una sección del otro portlet.
Puede combinarse con Asynchronous Server Side para refrescar la información del portlet de destino del mensaje.
Una implementación típica es a través de llamadas de Javascript que se comunican a través del navegador como si fuese una única página en html.
IPC en JSR 286
En la especificación 2.0 de Portlets se agregan dos formas de realizar IPC. Ambas son del lado del servidor y son las únicas formas estandarizadas de realizar IPC al momento de la release de la JSR 286.
Esta forma de implementarlo es a través de poner disponible para los portles la posibilidad de hacer visibles para otros portles ciertos parámetros render..
Events
Para la versión 2.0 de la especificación de Portlets se agregó una nueva fase entre la de "Process Action" y "Render" llamada "Process Events" y se establece un mecanismo para que los portlets puedan publicar eventos y suscribirse a los mismos.
El encargado de recolectar los eventos publicados y redistribuirlos es el portal.
Los eventos pueden publicarse durante la fase de "Process Action" y "Process Events" permitiendo que durante el procesamiento de un evento se puedan publicar nuevos eventos.
Todos los eventos se procesarán antes de comenzar con la fase de "Render".
Los eventos se publican a través del método setEvent de la clase ActionResponse y pueden ser procesados tanto en el método processEvents de la interfaz Portlet o anotando métodos con la anotación @ProcessEvent y especificando a que evento responderá el método. Este último es preferible ya que evita tener que identificar que evento se produjo dentro del cuerpo del método.
Ver también
- Eventos De JSR 286
- JSR 286 - Java Portlet Specification V2.0
- Portlet Con JSF
- JSF Portlet Bridge
