Lo anterior versus lo nuevo

La primera versión del nuevo portlet de Web Content Viewer fue proporcionado en IBM® Lotus® y WebSphere® Portal Business Solutions Catalog en Enero de 2009. Se incluyó una versión actualizada en un paquete de dispositivos de IBM WebSphere Portal V6.1.5 que fue publicado a fines del año 2009. Además de los muchos dispositivos nuevos, esta versión actualizada se basa en la segunda versión de Java Portlet Specification JSR 286. Aunque esto habilita muchos dispositivos nuevos, existe una desventaja al compararlo con con el Web Content Viewer anterior, el que estaba basado en la API del IBM Portlet: pasar un parámetro al viewer portlet hizo que un bit fuera más complejo. Sin embargo, como verñá en esta columna, también obtiene beneficios adicionales.

Volver arriba

¿Cómo funcionaba el antiguo portlet Web Content Viewer?

En la versión del visor de la API del IBM Portlet, usted simplemente añadía un parámetro de consulta a la URL abordando la página y todos los portlets de IBM de esa página recibían ese parámetro. A continuación usted configuró el portlet para escuchar las emisoras y creó una URL en el formato:

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

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

Este portlet es simple de utilizar, pero tiene los siguientes inconvenientes:

• Dado que el parámetro no se mantiene en la URL, debe ser almacenado en la sesión (incluso en el caso de uso anónimo) y por lo tanto afecta el consumo de memoria del servidor del portal.
• Una vez que haya interactuado con la página y el parámetro, éste no estará más en la URL -- pero estará almacenado en la sesión -- ya no podrá marcar más su selección.
• Para las páginas estáticas, el almacenamiento en el navegador no funciona porque la selección no está codificada en la URL. Esto significa que el navegador no puede distinguir entre news item 1 y news item 2 y, por lo tanto no puede almacenar el nivel del navegador.

Veamos cómo trabaja el visor en este nuevo mundo desafiante de JSR 286.

Volver arriba

¿Cómo funciona el portlet del Web Content View basado en JSR 286?

En el nuevo visor, usted utiliza la estructura de resolución URI de WebSphere Portal para abordar las páginas y los ítems de contenido desde los sistemas externos. La estructura de resolución de URI es una estructura genérica que también puede ser apalancada para los esquemas personalizados de URI. Web Content Management define el esquema wcm: de la siguiente manera:

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

Esto significa que usted provee la ruta de acceso al contenido y luego en forma opcional provee una de las siguientes opciones:

• Una página destino, utilizando el nombre exclusivo de la página o su ID objeto.
• Una correlación de URL.
• La página actual seleccionada en la URL que será utilizada antes de URI.

Si usted no proporciona ninguna de las opciones mencionadas anteriormente, WebSphere Portal trata automáticamente de encontrar la página correcta. Esto sólo funciona si usted está utilizando Web Content Pages, donde usted correlaciona un área del sitio Web Content Management con una página de portal de manera que WebSphere Portal conozca esa relación.

Entonces, ¿cómo obtiene usted una URL completa ahora? Usted tiene una par de opciones diferentes:

• Direccione la estructura de resolución WebSphere Portal directamente a través de /wps/poc o /wps/mypoc.
• Utilice cualquier URL para WebSphere Portal que sea reconocido por la aplicación externa.

Veamos una configuración de ejemplo en la biblioteca Web Content de Web Content Management que contiene lo siguiente:

• Un área del sitio llamada NewsUS y los ítems de los contenidos News1, News2 y News3.
• Un área del sitio llamada NewsEurope y los ítems de los contenidos News4, News5 y News6.
  
  Figura 1. Explorador de la Biblioteca
  
  
  
• Las siguientes páginas del portal con nombres familiares:
  • Nivel superior: Products, Company News
  • Segundo nivel: Products/Cars, Products/SUVs, Company News/US, Company News/Europe
  • US y y Europe son páginas de Web Content. US está correlacionada con el área Web Content/NewsUS del sitio Web Content Management, y Europe está correlacionada con el área Web Content/NewsEurope del sitio Web Content Management.

La Figura 2 muestra la sección avanzada de las propiedades de la página Europe donde aparece la correlación del área del sitio NewsEurope Web Content Management.

También definiremos la correlación de la URL para /coolCars con la página Products/Cars para que la URL http://host_name/wps/portal/coolCars lo lleve a http://host_name/wps/portal/Products/Cars.

Los siguientes son algunos de los ejemplos de URLs:

• Abordar directamente la estructura de resolución del portal:

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

  Esta URL le dice al portal que presente el ítem de contenido con la ruta de la biblioteca Web Content/NewsUS/News1. WebSphere Portal buscará la Web Content Page que se presente en el área del sitio NewsUS (Company News/US), lo volverá a enviar a la página, y definirá el contexto de esa página en la ruta de la biblioteca del ítem del contenido.

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

  Esta URL le indica a WebSphere Portal que presente el contenido del ítem del mismo modo que lo hizo con la URL anterior, pero en lugar de hacer la búsqueda de las páginas dinámicas, hacer un redireccionamiento a la página /Products/Cars, que se correlaciona con la URL /coolCars, como se muestra en la Fugura 3.

  
  
  Figura 3. Abordar la página destino mediante la correlación de la página con la de /coolCars to the selected Products/Cars
  
  
  
• Abordar la página a través de una URL conocida:

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

  Esta URL le indica a WebSphere Portal que seleccione la página /Company News/Europe y que presente el ítem de contenido Web Content/NewsUS/News2 en esta página. Observe que sin el parámetro current=true, WebSphere Portal se redireccionará a la página /Company News/US, porque ésa es la página que se correlaciona con el área del sitio NewsUS.

Debe haber al menos un portlet para el visor de contenido de la web JSR 286 en la página destino que debe ser configurado para recibir los vínculos desde otros portlets y desde éste, como lo muestra la Figura 5.

¿Por qué estas URLs están siendo utilizadas para abordar el portlet del nuevo visor, no del mismo modo que lo hace el esquema simple indicado anteriormente, sino por el contrario con todos estos caracteres especiales? Hablaremos de esto próximamente.

Volver arriba

Normas de codificación de la URL y de URI

Usted podría saber que las URLs válidas necesitan atenerse a algunas normas de codificación definidas en RFC 1738, y deben reemplazar a los caracteres reservados, tales como, " " (espacio) o ":". En el ejemplo mencionado anteriormente, el carácter " " (espacio) fue reemplazado por "+" y el carácter ":" fue reemplazado por un %3A.

Un detalle que no hemos explicado es el "urile" que aparece antes de la parte del esquema. En realidad existen dos posibilidades: usted puede especificar "uri" o "urile." La diferencia reside en que si usted utiliza el esquema uri necesitará seguir las siguientes normas de codificación URI además de las de codificación de la URL, por lo tanto la URL:

se vería de este modo utilizando el esquema "uri":

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

Vea RFC 3986 para obtener más información de cómo codificar los caracteres especiales para los URIs. Debido a que sería difícil construir a mano estos URIs, WebSphere Portal provee una versión de URI simplificada que sólo necesita ser codificada para la URL en lugar de codificarla para el URI utilizando el esquema de urile.

Volver arriba

¿Por qué la solución JSR 286 es diferente?

Java Portlet Specification V 2.0 (JSR 286) define algo denominado parámetro render que les es proporcionado a los portlets para cada solicitud. Por ejemplo, cuando el usuario pulsa el botón de recarga del navegador, el portlet obtiene los mismos parámetros render nuevamente y puede brindar la misma vista. Esto significa que el portlet ya no necesita almacenar la información sobre el estado de navegación en la sesión, como sucedía con los portlets basados en la API de IBM Portlet.

Existen dos tipos de parámetros render: privados, los que son privados para cada ventana del portlet de la página, y públicos, los que son compartidos. Los parámetros públicos le dan a usted la capacidad que tenía en la antigua API de IBM Portlet de añadir un parámetro de consulta a la URL y recibirlo con los portlets de la página. La solución del parámetro de consulta de la antigua API de IBM Portlet tiene dos desventajas:

• Sólo se obtiene el parámetro para una solicitud, después de eso cada porlet en la página necesita almacenar el valor en la sesión. Para ello es necesario tener sesiones, incluso en el caso de uso anónimo.
• Usted desconoce qué parámetro comprende un portlet, ya que los portlets no lo declaran formalmente. Usted incluso puede llegar a estar en una situación en donde dos portlets definan el mismo nombre de parámetro, pero con semánticas diferentes, lo que evitaría colocar estos dos portlets en la misma página, y usted no lo sabría de antemano.

Para superar estas limitaciones, las especificaciones de JSR 286 definen los parámetros públicos y utilizan el esquema de nomenclatura QName, muy conocida en los documentos XML (vea Namespaces in XML 1.0) para obtener el nombre de los parámetros. WebSphere Portal almacena el nombre y los valores de los parámetros como parte de las URLs en la página de modo que aquellas URLs sean factibles de ser marcadas y eviten usar una sesión. Debido a que es posible que usted tenga muchos parámetros render públicos y privados que necesite almacenar en la URL, necesita asegurarse de que las URLs no sean demasiado extensas. WebSphere Portal realiza esto utilizando la codificación de zip que surge de la URL, que luego se verá como esto:

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

Si un parámetro específico fuera demasiado grande, se almacena en la sesión y sólo la clave de la referencia se almacena en la URL. Esto ayuda a mantener a la URL por debajo del límite de tamaño de 2K impuestos por muchos navegadores u otros componentes de las infraestructuras de HTTP, tales como los proxies.

La desventaja de esta solución es que usted ya no podrá crear estos parámetros a mano debido a la codificación. Por lo tanto, Portal le proporciona el mecanismo anterior que consiste en agregar un simple URI al final del portal de la URL. Voila! Ahora tiene lo mejor de ambos mundos: usted está apalancando el patrón de estado de navegación definido por los parámetros render públicos JSR 286 y puede establecer fácilmente los parámetros en una URL específica.

Volver arriba

Conclusión

Al pasar del antiguo Web Content Viewer, un portlet de presentación Content Management, a una versión nueva basada en JSR 286, usted se beneficia con un montón de nuevas funcionalidades, como la capacidad de bookmark para almacenar el contexto seleccionado en la URL. Sin embargo, usted tiene la sensación de estar perdiendo un modo sencillo de enviar parámetros desde una aplicación externa al portlet de interpetación de Web Content Management. Esta columna describe una manera sencilla de recuperar la capacidad sin perder ninguna de los nuevos dispositivos usando un URI anexo a una URL.

Recursos

• IBM Lotus and WebSphere Portal Business Solutions Catalog
  
  
• JSR-286 Portlet Specification 2.0
  
  
• Namespaces in XML 1.0
  
  
• IBM developerWorks WebSphere
  
  
• IBM developerWorks WebSphere Portal zone
  
  

Sobre el autor

Stefan Hepper es arquitecto del producto de Lotus Web Content Management y parte del equipo de desarrollo del producto WebSphere Portal and Lotus Web Content Management. Sus responsabilidades anteriores, entre otras, incluyen haber sido programador en jefe de V6.1.5, líder de Java Portlet Specification V 2.0 (JSR 286). Ha dictado conferencias internacionales tal como JavaOne, ha publicado varios documentos y fue co-autor de los libros Pervasive Computing (Addison-Wesley 2001) y Programming Portlets: From JSR 168 to WebSphere Portal Extensions (McPress, 2007). Stefan recibió un Diploma en Ciencias de la Computación de la universidad de Karlsruhe, Alemania. Se unió al IBM Boeblingen Development Laboratory en 1998 y es parte del IBM Silicon Valley Lab desde el año 2009.

Califique este artículo

Comentario

Volver arriba

Tabla de contenidos

• Lo anterior versus lo nuevo
• ¿Cómo funcionaba el antiguo portlet Web Content Viewer?
• ¿Cómo funciona el portlet del Web Content View basado en JSR 286?
• Normas de codificación de la URL y de URI
• ¿Por qué la solución JSR 286 es diferente?
• Conclusión
• Recursos
• Sobre el autor
• Comentarios