Sending parameters from an external application to the Web Content Viewer portlet based on JSR 286

The information involved in this article refers only to URLs generated by external systems. URLs generated within the WebSphere Portal schema are simple and should use the URLCMPNT tag of IBM Web Content Management.

The first version of the new Web Content Viewer Portlet was provided in January 2009 in the Ibm®lotus®and websphere®portal Business Solutions Catalog. The upgraded version is released at the end of 2009, including the IBM WebSphere Portal V6.1.5 Feature Pack. In addition to many new features, the upgraded version is based on the Java Portlet specification JSR 286 2nd edition. Although this includes many new features, there is a disadvantage compared to the earlier Web Content Viewer (based on the IBM Portlet API): Passing a parameter to the viewer Portlet becomes a bit more complicated. In this column, you will have an unexpected benefit.

In the IBM portlet API version of the viewer, you simply add a query parameter to the URL that is looking for the page, which all IBM portlets will receive, and then you configure the Portlet to listen for the broadcast and create a URL in the following format:

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

For example: Http://mysystent/wps/portal/home?WCM_GOBAL_CONTEXT=/mynewslib/usnews/news1.

This portlet is simple to use, but it also has the following drawbacks:

Because of the restrictions that are displayed, some of the URLs shown in this article may appear to consist of multiple lines, but in fact, each URL is a contiguous row.

Because parameters cannot be saved in a URL, they are saved in a session (even in the case of asynchronous use), thus affecting the portal server memory consumption.

Once you interact with the page, the parameters are no longer in the URL-and stored in the session-you no longer need to bookmark your selections.

Static pages cached in the browser will no longer be valid because the selection cannot be encoded as a URL. This means that browsers cannot distinguish between news 1 and News 2 and therefore cannot be cached on the browser.

Let's take a look at how the New Era Viewer works in JSR 286.

In the new viewer, you can use the URI-factorization framework in the WebSphere Portal to find web pages or content items from the external system. The URI-factorization framework is a common framework that can also be used to facilitate custom URI patterns. Web Content Management definition mode WCM: as follows:

Wcm:path:library/site_area_path/content [[& page=unique_name | object_id] &mapping=mapping | &current= True

This means that you can provide a path to the content and choose to provide one of the following:

A target page that uses a unique page name or its object ID.

A URL map.

The current page, selected in the URL, to be used before the URI.

If you cannot provide any of these, the WebSphere Portal automatically tries to find the correct page. This method works only when you are using Web content pages, where you can map the Web content Management site area to the portal page for Webspher E Portal is aware of the connection between them.

So, how do you get a complete URL now? There are two different options:

Access the WebSphere Portal factorization framework directly through the/WPS/POC Or/wps/mypoc.

Any URLs that are known to the WebSphere Portal using external applications.