Ejercicio 1.2: Diferencias conceptuales entre las API

Antes de empezar, debe realizar el Ejercicio 1.1: Importar los recursos.

En este ejercicio se mostrarán las diferencias conceptuales entre las dos API de portlet.

Visión general

La API de portlet de IBM se desarrolló inicialmente para WebSphere Portal Versión 4. El soporte para la API de portlet de JSR 168 se proporcionó a partir de WebSphere Portal Versión 5.0.2.

La API de portlet JSR 168 es una especificación de portlet JavaTM estandarizada desarrollada por un grupo dirigido conjuntamente por IBM y Sun con participación de los proveedores principales de servidores de portal. El propósito de esta API es resolver los problemas de compatibilidad de portlet entre servidores de portal de distintos proveedores. La especificación inicial se aprobó en octubre de 2003.

WebSphere Portal soporta ambas API. Proporciona dos contenedores de portal: el contenedor heredado para los portlets de API de portlet de IBM portlet (a los que llamaremos portlets de IBM) y el contenedor estándar para los portlets de API de portlet de JSR 168 (a los que llamaremos portlets de JSR 168). Los portlets que se ejecutan en distintos contenedores pueden residir en la misma página de portal.

Un contenedor de portal proporciona el entorno de tiempo de ejecución para los portlets. Soporta el ciclo de vida del portlet que consta de estas tres fases:

La fase de manejo de peticiones tiene dos subfases:

Antes de entender las diferencias específicas en la codificación, debe entender algunas diferencias básicas entre las dos API de portlet.

Fíjese en que no es necesario que trabaje directamente con el código fuente de los descriptores de despliegue de portlet, tal como se indica a continuación. El editor del descriptor de despliegue de portlet proporciona una interfaz de usuario gráfica para portlet.xml y actualiza el código fuente.

Instancias de clase y datos que utilizan la API de portlet de IBM

La primera vez que se carga un portlet, se incializa con parámetros del descriptor de despliegue Web (web.xml). Los parámetros están definidos en el elemento <init-param> del elemento <servlet>. Estos parámetros pueden recuperarse utilizando el método getInitParameter() del objeto PortletConfig. El portlet resultante es un portlet abstracto.

Antes de utilizar un portlet, se cargan parámetros del descriptor de despliegue del portlet (portlet.xml) en un objeto PortletApplicationSettings o un objeto PortletSettings. Estos parámetros se establecen en el elemento <context-param> del elemento <concrete-portlet-app> y en el elemento <config-param> del elemento <concrete-portlet>.

Los parámetros del elemento <concrete-portlet-app> se aplican a todos los portlets de la aplicación de portlet; pueden recuperarse con el método PortletSettings.getApplicationSettings(). El método getApplicationSettings() devuelve un objeto PortletApplicationSettings y PortletApplicationSettings.getAttribute() se utiliza para recuperar los parámetros individuales. Los parámetros del elemento <concrete-portlet> se aplican a los portlets específicos; pueden recuperarse con el método PortletSettings.getAttribute().

La combinación de un portlet abstracto más los datos de un objeto PortletSettings se llama portlet concreto.

Cuando se pone un portlet en una página de portal, se crea un objeto PortletData. La combinación de un portlet concreto más un objeto PortletData se llama instancia de portlet concreto. Los objetos PortletData gestionan los datos persistentes para las instancias de portlet concretas. Los valores se recuperan utilizando los métodos PortletRequest.getData() y PortletData.getAttribute() y se almacenan utilizando los métodos PortletData.setAttribute() y PortletData.store(). Los datos abarcan un usuario o un grupo, dependiendo del ámbito de la página de portal.

La combinación de una instancia de portlet concreta más un objeto PortletSession se llama instancia de portlet de usuario.

La ilustración siguiente muestra los objetos que se acaban de tratar.
Representación lógica de clases de portlet y datos en la API de portlet de IBM

Instancias de clase y datos que utilizan la API de portlet de JSR 168

Utilizando la API de portlet de JSR 168, los parámetros iniciales se definen en portlet.xml con el elemento <portlet-preferences>. El elemento <init-param> de web.xml para la API de portlet de IBM es equivalente al elemento <init-param> en portlet.xml para la API de portlet de JSR 168.

Estos parámetros iniciales pueden establecerse como solo de lectura pero pueden modificarse en tiempo de ejecución en modalidad de configuración. Solo un administrador puede cambiar los parámetros de inicialización solo de lectura. Cuando se modifica durante el tiempo de ejecución, puede llamarse una clase de validador. El nombre de la clase de validador se establece también en el elemento <portlet-preferences>. El objeto PortletPreferences pone estos parámetros a disposición del portlet a través de los métodos RenderRequest.getPreferences(), PortletPreferences.getValue() y PortletPreferences.getValues(). El elemento <portlet-preferences> es equivalente al elemento <config-param> más el objeto PortletData en la API de portlet de IBM.

La combinación de un objeto PortletPreferences y de un portlet se conoce como entidad de portlet. Una ventana de portlet se define como la combinación del modelo de portlet (editar, ver), el estado de la ventana del portlet (normal, maximizado, minimizado) y los parámetros de representación. Una página de portal puede contener más de una ventana de portlet para un portlet dado, cada uno asociado con una modalidad, un estado y un conjunto de parámetros de representación específicos.

La ilustración siguiente muestra los objetos que se acaban de tratar.
Representación lógica de clases de portlet y datos en la API de JSR 168

Ciclo de vida del portlet

Ambas API de portlet utilizan un ciclo de vida que consta de una fase de inicialización, una fase de proceso de peticiones y una frase de destrucción. La fase de proceso de peticiones se divide en dos subfases: el proceso de la acciones y la representación de contenidos. Los detalles de la fase de proceso de peticiones se discuten en el Proceso de peticiones. Los métodos específicos llamados en cada fase se indican a continuación.

Métodos de ciclo de vida de la API de portlet de IBM

init(PortletConfig)
El método init() se llama cuando el portlet se pone en servicio. El parámetro PortletConfig proporciona acceso al objeto PortletContext.
initConcrete(PortletSettings)
El método initConcrete() se utiliza para inicializar el portlet concreto con el objeto PortletSettings.
service(PortletRequest, PortletResponse)
El método service() se llama cuando el portlet necesita representar su contenido. El método service se llama muchas veces durante el ciclo de vida de un portlet. Service llama a métodos como por ejemplo doView() y doEdit(), dependiendo del estado de la ventana del portlet. Normalmente el método service no se altera temporalmente en la clase de portlet de implementación.
destroyConcrete(PortletSettings)
El método destroyConcrete() se llama cuando el portlet concreto deja de estar en servicio.
destroy(PortletConfig)
El método destroy() se llama cuando el portlet deja de estar en servicio, proporcionando un lugar para el borrado de recursos.

Métodos de ciclo de vida de la API de portlet de JSR 168

init(PortletConfig)
El método init() se llama cuando el portlet se pone en servicio. El parámetro PortletConfig proporciona acceso al objeto PortletContext.
render(RenderRequest, RenderResponse)
El método render() se llama cuando el portlet necesita representar su contenido. Llama a métodos como por ejemplo doEdit() y doView(), dependiendo del estado de la ventana del portlet. Normalmente el método render no se altera temporalmente en la clase de portlet de implementación.
processAction(ActionRequest, ActionResponse)
El método processAction() necesita los objetos ActionRequest y ActionResponse como parámetros.
destroy()
El método destroy() se llama cuando el portlet deja de estar en servicio, proporcionando un lugar para el borrado de recursos.

Proceso de peticiones

Ambas API de portlet utilizan el proceso de peticiones en dos fases. Las acciones (o los eventos) se procesan primero y después se invoca la fase de representación. En la API de portlet de IBM, la fase de acción se invoca a través del método actionPerformed() y la fase de representación mediante el método service(). En la API de portlet de JSR 168, las fases se invocan a través de los métodos processAction() y render().

Una gran diferencia entre las dos API es que la API de portlet de JSR utiliza distintos objetos de petición y respuesta en las fases de acción y representación, mientras que la API de portlet de IBM utiliza los mismos objetos en las dos fases. Utilizando la API de portlet de IBM puede establecer atributos en los objetos de petición y respuesta durante el proceso de eventos y recuperar los valores durante la fase de representación. Con la API de portlet de JSR, los valores de atributo pueden pasarse utilizando el objeto de sesión o los parámetros de representación.

Otra diferencia es que el método actionPerformed() de la API de portlet de IBM utiliza el parámetro ActionEvent correspondiente para obtener acceso al objeto PortletRequest. El método processAction() de la API de portlet de JSR 168 tiene los parámetros ActionRequest y ActionResponse que implementan las interfaces PortletRequest y PortletResponse.

Ahora está preparado para iniciar el Ejercicio 1.3: Comparar diferencias de clase JavaTM.

Condiciones de uso | Comentarios
(C) Copyright IBM Corporation 2000, 2005. Reservados todos los derechos.