Diferencia entre revisiones de «Inter Portlet Communication»

De Dos Ideas.
Saltar a: navegación, buscar
Línea 15: Línea 15:
  
 
Todos los mensajes deben quedar resueltos antes de iniciarse la fase de Render.
 
Todos los mensajes deben quedar resueltos antes de iniciarse la fase de Render.
 
  
  
Línea 21: Línea 20:
  
 
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 32: Línea 30:
  
 
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.
 
  
  
Línea 38: Línea 35:
  
 
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.
 
  
  
Línea 44: Línea 40:
  
 
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..
 
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..
 
  
  

Revisión del 17:47 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)


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.


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

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