Artigos Java Portlets 3.0: Novos recursos para o desenvolvimento de portais
Por que eu devo ler este artigo:Portais são excelentes ferramentas para construir sites complexos. Com eles, é fácil criar diversas aplicações usando uma mesma plataforma e combiná-las em várias páginas, mantendo uma experiência de usuário consistente. Com a especificação de Portlets 3.0, na JSR-362, essa plataforma ficará ainda mais poderosa. Nessa versão, o desenvolvedor pode aproveitar CDI, dispensar os descritores XML e, finalmente, usar uma API JavaScript. Com esses avanços, os portais vão poder atender necessidades modernas, possibilitando a criação de sites mais rápidos, dinâmicos e com melhor usabilidade. Neste artigo, estudaremos essas novas ferramentas, de modo que o leitor esteja preparado para as mudanças que se aproximam.

A especificação de portlets mais recente, a JSR-286, foi aprovada em 2008. Deste então, muita coisa mudou, mas os portais não acompanharam essa evolução. Entre as várias tendências que não foram adotadas, podemos citar o JSF 2.0, CDI e anotações no lugar de descritores XML. Além disso, os requisitos também mudaram: aplicações web precisam ser muito mais dinâmicas, usando JavaScript pesadamente, e a busca por dinamicidade e respostas em real time tornaram a programação assíncrona uma necessidade. Diante desse novo cenário, não é surpresa que a especificação pareça tão defasada.

A boa notícia é que a JSR-362, versão 3.0 de portlets, já foi aprovada e publicada. Os vários portais Java já começaram a implementá-la e o desenvolvedor de portais pode estudar as novas APIs desde já.

Nesse artigo, conheceremos várias dessas funcionalidades. Começaremos pela nova fase de cabeçalho, utilizada para alterar campos HTTP e o elemento <head>. Com ela, não haverá mais a necessidade de executar a fase de renderização duas vezes. Posteriormente, analisaremos como os vários estágios de execução se relacionam com o estado de um portlet, assim como as novas interfaces que representam esses estados.

Outro importante avanço da JSR-362 é a melhor integração com o CDI. Para entender como funciona, estudaremos como utilizar beans gerenciados para implementar portlets, o que nos possibilitará o uso de injeção de dependências. Além disso, como anotações de configuração são uma parte importante dessa integração, uma análise dessas anotações também será realizada.

Por fim, exploraremos as APIs de front-end de Portlets 3.0. Essa nova versão traz mudanças há muito necessárias para criarmos portlets mais dinâmicos. Assim, veremos como utilizar a nova API de JavaScript, centrada no conceito de hub de portlet, para processar eventos no lado do cliente, alterar o estado do portlet e criar novos estados para se comunicar com o servidor.

Fase de cabeçalho

Frequentemente, um portlet precisa alterar a página na qual se apresenta. Por exemplo, para importar um arquivo CSS, definir valores de cookies e adicionar um campo no cabeçalho HTTP, é preciso mudar mais que o conteúdo do portlet.

Até o Portlet 2.0, a solução para isso era invocar a fase de renderização duas vezes. Isso exigia adicionar código ao método render(), além de habilitar obscuras opções de runtime.

Na JSR-362, temos uma solução mais madura. Portlet 3.0 especifica a fase de cabeçalho (header phase) para mudar os cabeçalhos HTTP, do documento e da janela do portlet. Para processar essa fase, a classe de portlet precisa implementar a interface HeaderPortlet, que possui apenas um método, renderHeaders().

Nota: Caso seus portlets estendam a classe GenericPortlet (como é o caso mais comum), então eles já implementam a interface HeaderPortlet. A única coisa que você precisa fazer, então, é sobrescrever renderHeaders().

Dentro de renderHeaders(), os cabeçalhos são alterados pelo objeto HeaderResponse. Assim, se quisermos definir um campo no cabeçalho HTTP, por exemplo, basta invocar o método addProperty(String, String). O primeiro argumento é o nome do campo HTTP, e o segundo é o valor, conforme o exemplo:

  headerResponse.addProperty("Warning", "199 Miscellaneous warning");

Já para criar um cookie, é preciso chamar o método addPortlet(Cookie). Primeiramente, no entanto, precisamos criar uma instância de Cookie, com o nome e o valor desejados, e então a passamos como parâmetro, conforme o código:

  Cookie cookie = new Cookie("CART_ID", carrinhoId);
  headerResponse.addProperty(cookie);

Nesta fase também adicionamos conteúdo ao cabeçalho HTML. Se o conteúdo é um elemento HTML (como links para CSS ou tags <meta>), podemos instanciar o elemento chamando createElement(). Feito isso, para adicionar esse novo elemento, usamos o método addProperty(String, Element). Nesse caso, o primeiro argumento deve ser a constante javax.portlet.MimeResponse.MARKUP_HEAD_ELEMENT, pois de outro modo o portal assumiria que o nó seria mais um cabeçalho HTTP.

Um bom exemplo de uso dessa opção (vide Listagem 1) é adicionar folhas de estilo, já que não podem ser declaradas no corpo do documento.

Listagem 1. Adicionando CSS ao cabeçalho do documento.

  @Override
  public void renderHeaders(HeaderRequest request, HeaderResponse response) {
   Element estiloInterno = response.createElement("style");
   estiloInterno.setTextContent(".perigo {color: red}");
   response.addProperty(MimeResponse.MARKUP_HEAD_ELEMENT, estiloInterno);
  }

Aqui, é válido ressaltar que nem todo conteúdo do elemento <head> é um elemento HTML – comentários, por exemplo, não são. Nesses casos, devemos escrever diretamente no cabeçalho do documento. Isso é feito utilizando o PrintWriter retornado por HeaderResponse.getWriter(), como demonstra a Listagem 2.

Listagem 2. Escrevendo um comentário no elemento <head>.

  @Override
  public void renderHeaders(HeaderRequest request, HeaderResponse response)
  throws PortletException, IOException {
   response.getWriter().write("<!-- Comentário no header -->");
  }
Nota: Escrever diretamente no cabeçalho é algo a ser evitado. Um caso de uso onde isso é justificável é adicionar comentários condicionas do Internet Explorer para importar folhas de estilo com hacks CSS. Felizmente, é algo bem menos necessário hoje em dia, mas caso seja preciso, já sabemos como fazê-lo.

Por fim, também podemos alterar o título do portlet na fase de cabeçalho. Para isso, a interface HeaderResponse possui o método setTitle(String).

Neste momento é importante ter em mente que a execução dessas operações pode ser bloqueada se o portal considerá-la insegura. Por exemplo, uma implementação da JSR-362 pode impedir que o elemento <title> seja adicionado ao <head>. Do mesmo modo, um portal provavelmente se recusaria a definir o campo HTTP Location para evitar redirecionamentos. Ainda assim, necessidades mais comuns, como adicionar arquivos CSS, dificilmente terão restrições.

Estágios de execução de um portlet

Além da fase de cabeçalho, portlets, na JSR-362, podem executar as outra quatro já especificadas atualmente: ação, processamento de eventos, renderização e provimento de recursos. Essas fases são executadas em ordens predefinidas e podem ser agrupadas em estágios de execução portlet.

Quais estágios serão processados depende do tipo de requisição. Por exemplo, ao processar uma requisição de ação, o portal inicia a fase de ação, durante a qual o portlet executa algum processamento, como alterar o banco de dados. Caso eventos sejam publicados durante a ação, eles serão processados na fase de eventos. Essas duas fases podem alterar parâmetros de renderização e o estado do portlet, preparando-o para ser renderizado. Logo, dizemos que essas fases formam o estágio de preparação (preparation stage).

Após o estágio de preparação, processa-se o cabeçalho. Posteriormente, vem a fase de renderização, quando o portlet gera um fragmento de HTML para compor a página. Nas fases de cabeçalho e renderização não é mais possível alterar os parâmetros do portlet: podemos apenas gerar conteúdo para ser mostrado. Assim, elas formam o estágio de marcação (markup stage).

A Figura 1 representa esses estágios em um diagrama. Note que, se a requisição for gerada por uma render URL, só é possível executar o estágio de marcação.

As fases e os estágios de execução de uma requisição a um portlet
Figura 1. As fases e os estágios de execução de uma requisição a um portlet

Por fim, portlets podem atender requisições apenas para prover recursos. Nesse caso, a fase provimento de recurso do portlet que é executada. Ela permite o download de recursos como imagens e JSON, além de responder a requisições de JavaScript. Assim como no estágio de marcação, não é possível alterar o estado de renderização do portlet ao servir um recurso.

Originalmente, a fase de provimento de recurso era executada sozinha e a requisição de um recurso não poderia alterar o estado do portlet. Contudo, Portlet 3.0 traz o novo conceito de ação parcial: uma requisição de ação que retorna, na verdade, recursos para um framework web (por exemplo, JSF). O processamento de uma requisição de ação parcial tem dois estágios: o estágio de preparação, já conhecido, e o estágio de recurso.

Os estágios de uma requisição de recurso podem ser vistos na Figura 2.

As fases e os estágios de execução de uma requisição de recurso
Figura 2. As fases e os estágios de execução de uma requisição de recurso
Nota: Ações parciais não são muito usadas no dia a dia: são uma funcionalidade para criadores de frameworks. Assim, a maioria das requisições de recurso executarão apenas o estágio de recurso. Portanto, é importante saber de sua existência, mas seu uso te ...

Quer ler esse conteúdo completo? Tenha acesso completo