Linhas de comentários: Enviando parâmetros para o Web Content Viewer Portlet baseado em JSR 286 a partir de aplicativos externos

O novo Web Content Viewer Portlet baseado em JSR 286, que faz parte do IBM® WebSphere® Portal V6.1.5, adiciona muitos recursos novos e oferece muitas vantagens. Entretanto, se você quiser enviar parâmetros de um aplicativo externo para o portlet, o funcionamento do novo portlet é muito diferente do antigo. Este artigo descreve como enviar parâmetros facilmente para o novo portlet e explica por que essa diferença existe. Este conteúdo é parte do IBM WebSphere Developer Technical Journal.

Stefan Hepper, WebSphere Portal Programming Model Architect, IBM

Author photoStefan Hepper é arquiteto do produto Lotus Web Content Management e integrante da equipe de desenvolvimento dos produtos WebSphere Portal e Lotus Web Content Management. Suas responsabilidades anteriores incluíram, entre outras, as de programador executivo da V6.1.5 e líder da Java Portlet Specification V 2.0 (JSR 286). Ministrou palestras em conferências internacionais, como JavaOne, publicou vários estudos e foi coautor dos livros Pervasive Computing (Addison-Wesley 2001) e Programming Portlets: From JSR 168 to WebSphere Portal Extensions (McPress, 2007). Stefan formou-se em Ciência da Computação pela Universidade de Karlsruhe, Alemanha. Ingressou no IBM Boeblingen Development Laboratory em 1998 e faz parte do IBM Silicon Valley Lab desde 2009.


nível de autor Profissional do
        developerWorks

30/Jul/2010

Antigo versus novo

UrlCmpnt

A primeira versão do novo Web Content Viewer Portlet foi fornecida no IBM® Lotus® and WebSphere® Portal Business Solutions Catalog em janeiro de 2009. Uma versão atualizada foi incluída no IBM WebSphere Portal V6.1.5 Feature Pack introduzido no final de 2009. Além de muitos recursos novos, essa versão atualizada é baseada na segunda versão da Java Portlet Specification JSR 286. Embora isso permita a inclusão de muitos recursos novos, há uma desvantagem em comparação com o Web Content Viewer anterior, que era baseado na API de Portlet IBM: a passagem de um parâmetro para o portlet visualizador tornou-se ligeiramente mais complexa. Entretanto, como você verá nesta coluna, também há benefícios adicionais.


Como o antigo Web Content Viewer Portlet funcionava

Na versão do visualizador baseada na API de Portlet IBM, você simplesmente adicionava um parâmetro de consulta a uma URL que endereçava a página e todos os portlets IBM nessa página recebiam esse parâmetro. Em seguida, você configurava o portlet para ouvir transmissões e criava uma URL no seguinte formato:

Listagem 1
http://[PORTAL_HOST]/[PORTAL_CONTEXT_ROOT]/[PORTAL_PAGE_URL_MAPPING]/?WCM_GLOBAL_CONTEXT=
<pathCmpnt type="noprefixservlet" />/[LIBRARY]/[SITE]/[SITE_AREA_PATH]/[CONTENT]

Por exemplo: http://mysystent/wps/portal/home?WCM_GOBAL_CONTEXT=/mynewslib/usnews/news1.

Esse portlet é fácil de usar, mas tem os seguintes inconvenientes:

  • Como não é mantido na URL, o parâmetro deve ser armazenado na sessão (mesmo no caso de uso anônimo), afetando, portanto, o consumo de memória do servidor de portal.
  • Depois que você interage com a página e o parâmetro não está mais na URL, mas armazenado na sessão, não é mais possível criar um marcador da sua seleção.
  • Para páginas estáticas, o armazenamento no cache do navegador não funciona, porque a seleção não é codificada na URL. Isso significa que o navegador não consegue diferenciar a notícia 1 da notícia 2 e, portanto, não pode armazená-las no cache em nível de navegador.

Examinemos como o visualizador funciona no admirável mundo novo da JSR 286.


Como o Web Content Viewer Portlet baseado em JSR 286 funciona

No novo visualizador, a estrutura do resolvedor de URI do WebSphere Portal é usada para endereçar páginas e itens de conteúdo a partir de sistemas externos. A estrutura do resolvedor de URI é uma estrutura de resolvedor genérico que também pode ser aproveitada em esquemas de URI customizados. O Web Content Management define o esquema wcm: da seguinte forma:

wcm:path:LIBRARY/SITE_AREA_PATH/CONTENT [[& page=unique_name | object_id] &mapping=mapping | &current=true]

Isso significa que você fornece o caminho para o conteúdo e, opcionalmente, um dos seguintes elementos:

  • Uma página de destino, usando o nome exclusivo da página ou seu ID de objeto.
  • Um mapeamento de URL.
  • A página atual selecionada na URL para ser usada antes do URI.

Caso nenhum desses elementos seja fornecido, o WebSphere Portal automaticamente tenta localizar a página correta. Isso só funciona se você estiver usando as Páginas de Conteúdo da Web, onde a área de um site de Gerenciamento de Conteúdo da Web é mapeada a uma página de portal de modo que o WebSphere Portal esteja ciente da relação.

Portanto, como obter uma URL completa agora? Há duas opções:

  • Endereçar a estrutura de resolvedor do WebSphere Portal diretamente por meio de /wps/poc ou /wps/mypoc.
  • Usar qualquer URL para o WebSphere Portal que seja conhecida pelo aplicativo externo.

Examinemos um exemplo de configuração na biblioteca Web Content do Web Content Management, que contém:

  • Uma área de site chamada NewsUS e os itens de conteúdo News1, News2 e News3.
  • Uma área de site chamada NewsEurope e os itens de conteúdo News4, News5 e News6.
    Figura 1. Library Explorer
    Figure 1. Library Explorer
  • As seguintes páginas de portal com nomes amigáveis:
    • Nível superior: Products, Company News
    • Segundo nível: Products/Cars, Products/SUVs, Company News/US, Company News/Europe
    • US e Europe são páginas de Conteúdo da Web. US é mapeada para a área de site Web Content/NewsUS e Europe é mapeada para a área de site Web Content/NewsEurope do Web Content Management.

A Figura 2 mostra a seção avançada das propriedades da página Europe exibindo o mapeamento à área de site NewsEurope do Web Content Management.

Figura 2. Seção avançada das propriedades da página Europe
Figure 2. Advanced section of the Europe page properties

Definiremos também um mapeamento de /coolCars à página Products/Cars para que a URL http://host_name/wps/portal/coolCars conduza o usuário para http://host_name/wps/portal/Products/Cars.

Estes são alguns exemplos de URLs:

  • Endereçando diretamente a estrutura de resolvedor do portal:

    http://host_name/wps/mypoc?urile=wcm%3Apath%3A/Web+Content/NewsUS/News1

    Esta URL determina ao portal que renderize o item de conteúdo com o caminho da biblioteca Web Content/NewsUS/News1. O WebSphere Portal procurará a Página de Conteúdo da Web que está mapeada à área de site NewsUS (Company News/US), redirecionará para essa página e definirá o caminho da biblioteca do item de conteúdo como o contexto dessa página.

  • http://host_name/wps/mypoc?urile=wcm%3Apath%3A/Web+Content/NewsUS/News1&mapping=/coolCars

    Essa URL determina ao WebSphere Portal que renderize o item de conteúdo da mesma maneira que a URL anterior, mas, em vez de fazer a consulta dinâmica da página, que execute um redirecionamento para a página /Products/Cars, que está mapeada à URL /coolCars, como é mostrado na Figura 3.

    Figura 3. Endereçando a página de destino por meio do mapeamento de /coolCars à página Products/Cars selecionada
    Figure 3. Addressing the target page by mapping /coolCars to the selected Products/Cars page
  • Endereçando o portal por meio de uma URL amigável:

    http://host_name/wps/portal/Company+News/Europe?urile=wcm%3Apath%3A/Web+Content/NewsUS/News2&current=true

    Essa URL determina ao WebSphere Portal que selecione a página /Company News/Europe e renderize o item de conteúdo Web Content/NewsUS/News2 nessa página. Observe que sem o parâmetro current=true, o WebSphere Portal redirecionaria para a página /Company News/US, porque essa é a página que está mapeada à área de site NewsUS.

Figura 4. Endereçando a página usando o caminho de URL amigável Company News/Europe e renderizando a área de site USNews
Figure 4. Addressing the page using the friendly URL path Company News/Europe and rendering the USNews site area

Deve haver pelo menos um Web Content Viewer Portlet JSR 286 na página de destino e ele deve estar configurado para receber links de outros portlets e desse portlet, como é mostrado na Figura 5.

Figura 5. Web Content Viewer Portlet JSR 286 configurado para receber links de outros portlets
Figure 5. JSR 286 Web Content Viewer Portlet configured to receive links from other portlets

Por que essas URLs usadas para endereçar o novo portlet visualizador não são tão elegantes quanto o esquema simples indicado acima, contendo, em vez disso, todos esses caracteres especiais? Discutiremos isso a seguir.


Regras de codificação de URL e URI

Talvez você saiba que URLs válidas devem seguir regras de codificação específicas definidas na RFC 1738 e devem substituir caracteres reservados como " " (espaço) ou ":". No exemplo acima, o caractere " " (espaço) foi substituído por "+" e o caractere ":" foi substituído por %3A.

Um detalhe que não foi explicado é o "urile" que aparece antes da parte do esquema. Na verdade, há duas opções: é possível especificar "uri" ou "urile". A diferença é que, se o esquema uri for usado, será preciso seguir as regras de codificação de URI além das regras de codificação de URL, de modo que a URL:

http://host_name/wps/portal/Company+News/NewsEurope?urile=wcm%3Apath%3A/Web+Content/NewsUS/News2&current=true

ficará assim usando o esquema "uri":

http://host_name/wps/portal/Company+News/NewsEurope?uri=wcm%253Apath%253A%2FWeb%2BContent%2FNewsUS%2FNews2%26current%3Dtrue

Consulte a RFC 3986 para obter mais informações sobre como codificar caracteres especiais para URIs. Como seria difícil construir esses URIs manualmente, o WebSphere Portal fornece uma versão de URI simplificada que só precisa ser codificada como URL, não como URI, usando o esquema urile.


Por que a solução JSR 286 é diferente

A Java Portlet Specification V 2.0 (JSR 286) define algo conhecido como parâmetro de renderização que é fornecido aos portlets em cada solicitação. Por exemplo, quando o usuário pressiona o botão de recarregar do navegador, o portlet recebe novamente os mesmos parâmetros e pode renderizar a mesma visualização. Isso significa que o portlet não precisa mais armazenar essas informações de estado de navegação na sessão, como era o caso com os portlets baseados na API de Portlet IBM.

Há dois tipos diferentes de parâmetros de renderização: privados, que são privados para cada janela de portlet na página, e públicos, que são compartilhados. Os parâmetros públicos lhe proporcionam a capacidade que havia na antiga API de Portlet IBM de adicionar um parâmetro de consulta à URL e recebê-lo com os portlets na página. A solução de parâmetro de consulta da antiga API de Portlet IBM tem duas desvantagens:

  • Apenas o parâmetro de uma única solicitação é recebido; depois disso, cada portlet na página precisa armazenar o valor na sessão. Isso exige que haja sessões mesmo no caso do uso anônimo.
  • Não se sabe qual parâmetro um portlet reconhece, pois os portlets não declaram isso formalmente. Pode até ocorrer uma situação em que dois portlets definam o mesmo nome de parâmetro, mas com semântica diferente, o que impediria a colocação de ambos na mesma página – e não se saberia disso de antemão.

Para superar essas limitações, a especificação JSR 286 define parâmetros públicos e usa o esquema de nomenclatura QName, já bem conhecido dos documentos XML (consulte o nome do parâmetro em Namespaces in XML 1.0). O WebSphere Portal armazena o nome e o valor do parâmetro como parte das URLs na página, permitindo que essas URLs sejam incluídas nos marcadores e evitando o uso de uma sessão. Como talvez existam muitos parâmetros de renderização públicos e privados que devem ser armazenados na URL, é necessário certificar-se de que as URLs não ficarão excessivamente longas. O WebSphere Portal faz isso aplicando uma codificação zip a essa parte da URL, que passa a ter a seguinte aparência:

Listagem 2
http://sh1.svl.ibm.com:10046/wps/myportal/Home/Company-News/us/!
ut/p/b1/hc7LDoIwEIXhZ_EBzExppbIcSxSUi4AidGNIvAQiaiLB6NOLxo0LddbffzKgIRcmsyRyxiEDfSzacl805
elYHCAHreU6Sv3YkbGBkzGZ6LrWwHFtwRElZG25vT4zbX5nZgfyDqgJOUJ6iEOaPoGwpnMaMCT2r19BhmKdVMOzf2
sy767aRXWPsKkiI6jU7WJH1yZYzDdpvByRvULy6q7Rn7OhP1Pd7CzkPFQME-MNfr31AvjlCCFwTvUWat36513i9qn
XewCN50jf/#Z7_QVMRH7R20GFA60II95HID43007

Caso um parâmetro específico fique longo demais, ele é armazenado na sessão e somente a chave de referência é armazenada na URL. Isso ajuda a manter a URL abaixo do limite de tamanho de 2 K imposto por muitos navegadores e outros componentes da infraestrutura HTML, como proxies.

A desvantagem dessa solução é que se torna impossível criar esses parâmetros manualmente devido à codificação. Portanto, o Portal lhe oferece o mecanismo descrito acima de adição de um URI simples no final de uma URL de portal. Voilà! Agora você tem o melhor dos dois mundos: ao mesmo tempo em que aproveita o padrão de estado de navegação definido por meio dos parâmetros públicos de renderização da JSR 286, você pode definir parâmetros facilmente em uma URL específica.


Conclusão

Ao migrar do antigo Web Content Viewer, um portlet de renderização do Web Content Management, para a nova versão baseada em JSR 286, você ganha muitas funcionalidades novas, como a possibilidade de marcação por meio do armazenamento do contexto selecionado na URL. Entretanto, você também parece perder uma maneira simples de enviar parâmetros de um aplicativo externo para o portlet de renderização do Web Content Management. Esta coluna descreveu uma maneira simples de recuperar essa capacidade sem perder nenhum dos novos recursos, usando uma URI anexada à URL.

Recursos

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Lotus, WebSphere
ArticleID=503008
ArticleTitle=Linhas de comentários: Enviando parâmetros para o Web Content Viewer Portlet baseado em JSR 286 a partir de aplicativos externos
publish-date=07302010