Comentarios: Envío de los parámetros al portlet Web Content Viewer basados en JSR 286 de las aplicaciones externas

El portlet Web Content Viewer basado en el nuevo JSR 286 que forma parte de IBM® WebSphere® Portal V6.1.5 añade muchos dispositivos nuevos y tiene muchas ventajas. Sin embargo, si usted quiere enviar los parámetros de una aplicación externa a un portlet funciona de modo muy diferente en el nuevo portlet si se lo compara con el anterior. Este artículo describe cómo puede enviar fácilmente los parámetros al nuevo portlet y por qué existe esa diferencia. This content is part of the IBM WebSphere Developer Technical Journal.

Stefan Hepper, WCM Architect, IBM

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.


Nivel de autor profesional en developerWorks

14-07-2010

Lo anterior versus lo nuevo

La información de este documento se refiere sólo a las URLs generadas por los sistemas externos. Las URLs generadas dentro del marco de WebSphere Portal serán simples y deberían utilizar la etiqueta IBM Web Content Management UrlCmpnt.

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.


¿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:

Listado 1
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:

Debido a las restricciones para su visualización, algunas de las URLs mostradas en este artículo podrían aparecer como si estuvieran constituidas por varias líneas. En la práctica, cada URL sería en realidad una única línea continua.

  • 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.


¿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
    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.

La Figura 2 muestra la sección avanzada de las propiedades de la página Europe
Figura 2. Sección avanzada de las propiedades de la página Europe

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
    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.

Figura 4. Abordar la página usando la ruta de la URL conocida Company News/Europe y presentar el área del sito USNews
Figura 4. Abordar la página usando la ruta URL conocida Company News/Europe y presentar el área del sitio USNews

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.

Figura 5. JSR 286 Web Content Viewer Portlet configurado para recibir los vínculos desde otros portlets
Figura 5. JSR 286 Web Content Viewer Portlet configurado para recibir los vínculos desde otros portlets

¿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.


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:

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

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.


¿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:

Listado 2
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.


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

Comentarios

developerWorks: Ingrese

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


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

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

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere, Lotus
ArticleID=964607
ArticleTitle=Comentarios: Envío de los parámetros al portlet Web Content Viewer basados en JSR 286 de las aplicaciones externas
publish-date=07142010