Exercício 1.2: Diferenças Conceituais entre as APIs

Antes de começar, você deve concluir o Exercício 1.1: Importando os Recursos.

Neste exercício, você aprenderá as diferenças conceituais entre as duas APIs de portlet.

Visão Geral

A API de portlet IBM foi inicialmente desenvolvida para o WebSphere Portal Versão 4. O suporte para a API de portlet JSR 168 foi fornecida começando com o WebSphere Portal versão 5.0.2.

A API de portlet JSR 168 é uma especificação padronizada do portlet JavaTM, desenvolvida por um grupo que foi co-liderado pela IBM e Sun, com a participação dos principais fornecedores de servidores de portal. Sua finalidade é solucionar questões de compatibilidade de portlets entre servidores de portais de diferentes fornecedores. A especificação inicial foi aprovada em outubro de 2003.

O WebSphere Portal suporta ambas as APIs. Ele fornece dois contêineres de portal: o contêiner legacy para portlets da API de portlet IBM (daqui em diante chamados de portlets IBM) e o contêiner Default (Padrão) para portlets da API de portlet JSR 168 (daqui em diante chamados de portlets JSR 168). Os portlets executados em contêineres diferentes podem residir na mesma página do portal.

Um contêiner de portal fornece o ambiente de tempo de execução para portlets. Ele suporta o ciclo de vida do portlet, que consiste nestas três fases:

A fase de manipulação de pedidos possui estas subfases:

Antes de entender as diferenças específicas da codificação, você precisa entender algumas diferenças básicas entre as duas APIs de portlet.

Observe que não é necessário trabalhar diretamente com o código fonte para os descritores de implementação de portlet, conforme descrito aqui. O editor do descritor de implementação de portlet fornece uma interface gráfica com o usuário para o portlet.xml e atualiza o código fonte para você.

Instâncias e Dados da Classe Utilizando a API de Portlet IBM

Quando um portlet é inicialmente carregado, ele é inicializado com os parâmetros do descritor de implementação da Web (web.xml). Os parâmetros são definidos no elemento <init-param> do elemento <servlet>. Esses parâmetros podem ser recuperados utilizando o método getInitParameter() do objeto PortletConfig. O portlet resultante é um portlet abstrato.

Antes da utilização de um portlet, os parâmetros do descritor de implementação do portlet (portlet.xml) são carregados em um objeto PortletApplicationSettings ou em um objeto PortletSettings. Esses parâmetros são definidos no elemento <context-param> do elemento <concrete-portlet-app> e no elemento <config-param> do elemento <concrete-portlet>.

Os parâmetros no elemento <concrete-portlet-app> aplicam-se a todos os portlets no aplicativo de portlet; eles podem ser recuperados com o método PortletSettings.getApplicationSettings(). O método getApplicationSettings() retorna um objeto PortletApplicationSettings e o PortletApplicationSettings.getAttribute() é utilizado para recuperar parâmetros individuais. Os parâmetros no elemento <concrete-portlet> aplicam-se a portlets específicos; eles podem ser recuperados com o método PortletSettings.getAttribute().

A combinação de um portlet abstrato e dos dados de um objeto PortletSettings é chamada de portlet concreto.

Quando um portlet é colocado em uma página do portal, um objeto PortletData é criado. A combinação de um portlet concreto e um objeto PortletData é chamada de instância de portlet concreto. Os objetos PortletData gerenciam os dados persistentes para as instâncias de portlet concreto. Os valores são recuperados utilizando os métodos PortletRequest.getData() e PortletData.getAttribute() e armazenados utilizando os métodos PortletData.setAttribute() e PortletData.store(). O escopo dos dados é definido para um usuário ou grupo, dependendo do escopo da página do portal.

A combinação de uma instância de portlet concreto e de um objeto PortletSession é chamada de instância de portlet do usuário.

A ilustração a seguir mostra os objetos mencionados.
Representação Lógica de Classes e Dados do Portlet na API de Portlet IBM

Instâncias e Dados de Classe Utilizando a API de Portlet JSR 168

Utilizando a API de portlet JSR 168, parâmetros iniciais são definidos no portlet.xml com o elemento <portlet-preferences>. O elemento <init-param> no web.xml para a API de portlet IBM é equivalente ao elemento <init-param> no portlet.xml para a API de portlet JSR 168.

Esses parâmetros iniciais podem ser definidos como de leitura, mas podem ser modificados no tempo de execução no modo Config. Apenas um administrador pode alterar os parâmetros de inicialização de leitura. Quando modificados durante o tempo de execução, uma classe de validador pode ser chamada. O nome da classe de validador também é definido no elemento <portlet-preferences>. O objeto PortletPreferences torna esses parâmetros disponíveis para o portlet por meio dos métodos RenderRequest.getPreferences(), PortletPreferences.getValue() e PortletPreferences.getValues(). O elemento <portlet-preferences> é equivalente ao elemento <config-param> mais um objeto PortletData na API de portlet IBM.

A combinação de um objeto PortletPreferences e um portlet é conhecida como entidade de portlet. Uma janela de portlet é definida como a combinação do modo do portlet (editar, visualizar), o estado da janela do portlet (normal, maximizado, minimizado) e os parâmetros de processamento. Uma página do portal pode conter mais de uma janela de portlet para um determinado portlet, cada uma delas associada a um modo, estado e conjunto específico de parâmetros de processamento.

A ilustração a seguir mostra os objetos mencionados.
Representação Lógica de Classes e Dados do Portlet na API JSR 168

Ciclo de Vida do Portlet

Ambas as APIs de portlet utilizam um ciclo de vida que consiste em uma fase de inicialização, uma fase de processamento do pedido e uma fase de destruição. A fase de processamento do pedido é dividida em subfases: processamento da ação e processamento do conteúdo. Os detalhes da fase de processamento do pedido são descritos em Processamento do Pedido. Os métodos específicos chamados em cada fase são listados a seguir.

Métodos de Ciclo de Vida da API de Portlet IBM

init(PortletConfig)
O método init() é chamado quando o portlet é colocado em serviço. O parâmetro PortletConfig fornece o acesso ao objeto PortletContext.
initConcrete(PortletSettings)
O método initConcrete() é utilizado para inicializar o portlet concreto com o objeto PortletSettings.
service(PortletRequest, PortletResponse)
O método service() é chamado quando o portlet precisa processar seu conteúdo. O método service é chamado várias vezes durante o ciclo de vida de uma portlet. As chamadas de serviço, como doView() e doEdit(), dependendo do estado da janela do portlet. Geralmente, o método service não é substituído na implementação da classe do portlet.
destroyConcrete(PortletSettings)
O método destroyConcrete() é chamado quando o portlet concreto é retirado de serviço.
destroy(PortletConfig)
O método destroy() é chamado quando o portlet é retirado de serviço, fornecendo um local para a limpeza de recursos.

Métodos de Ciclo de Vida da API de Portlet JSR 168

init(PortletConfig)
O método init() é chamado quando o portlet é colocado em serviço. O parâmetro PortletConfig fornece o acesso ao objeto PortletContext.
render(RenderRequest, RenderResponse)
O método render() é chamado quando o portlet precisa processar seu conteúdo. Ele chama métodos, como doEdit() e doView(), dependendo do estado da janela do portlet. Geralmente, o método de processamento não é substituído na implementação da classe do portlet.
processAction(ActionRequest, ActionResponse)
O método processAction() requer objetos ActionRequest e ActionResponse como parâmetros.
destroy()
O método destroy() é chamado quando o portlet é retirado de serviço, fornecendo um local para a limpeza de recursos.

Processamento do Pedido

Ambas as APIs de portlet utilizam o processamento do pedido em duas fases. As ações (ou eventos) são processadas primeiro, depois a fase de processamento é chamada. Na API de portlet IBM, a fase de ação é chamada por meio do método actionPerformed() e a fase de processamento é chamada pelo método service(). Na API de portlet JSR 168, as fases são chamadas por meio dos métodos processAction() e render().

Uma grande diferença entre as duas APIs é que a API de portlet JSR utiliza diferentes objetos de pedido e resposta nas fases de ação e de processamento, enquanto a API de portlet IBM utiliza os mesmos objetos nas duas fases. Utilizando a API de portlet IBM, você pode definir atributos nos objetos de pedido e resposta durante o processamento do evento e recuperar os valores durante a fase de processamento. Utilizando a API de portlet JSR, os valores de atributos podem ser transmitidos utilizando o objeto de sessão ou utilizando parâmetros de processamento.

Uma outra diferença é que o método actionPerformed() da API de portlet IBM utiliza seu parâmetro ActionEvent para obter acesso ao objeto PortletRequest. O método processAction() da API de portlet JSR 168 possui os parâmetros ActionRequest e ActionResponse, que implementam as interfaces PortletRequest e PortletResponse.

Agora você está pronto para começar Exercício 1.3: Comparando Diferenças da Classe JavaTM.

Feedback
(C) Copyright IBM Corporation 2000, 2005. Todos os Direitos Reservados.