JSR 286 Content Viewer Portlet vs IBM Content Viewer Portlet(till 6.0)

This Article describes differences between the IBM Content Viewer and JSR 286 version of Content viewer


IBM Content Viewer Portlet (till 6.0.1)
In the IBM Portlet API version of the viewer, you can simply add a query parameter to a URL addressing the page and all the IBM portlets on that page received that parameter. You then configured the portlet to listen to broadcasts and created a URL in the format:

http://[PORTAL_HOST]/[PORTAL_CONTEXT_ROOT]/[PORTAL_PAGE_URL_MAPPING]

/?WCM_GLOBAL_CONTEXT=<pathCmpnt type="noprefixservlet" />/[LIBRARY]/[SITE]

/[SITE_AREA_PATH]/[CONTENT]

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

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

• Since the parameter is not maintained in the URL, it needs to be stored in the session (even in the case of anonymous use) and therefore impacts portal server memory consumption.
• Once you’ve interacted with the page and the parameter is no longer in the URL -- but stored in the session -- you can no longer bookmark your selection.
• For static pages, caching in the browser doesn’t work because the selection is not encoded into the URL. This means the browser can’t distinguish between news item 1 and news item 2 and therefore cannot cache on the browser level.

The query parameter solution of the old IBM Portlet API has two disadvantages:

• You only get the parameter for one request; after that each portlet on the page needs to store the value in the session. This requires having sessions even in the case of anonymous use.
• You don't know what parameter a portlet understands, as the portlets don’t formally declare this. You can even run in a situation where two portlets define the same parameter name, but with different semantics that would prevent you from putting these two portlets onto the same page, and you wouldn’t know this beforehand.

JSR 286 Content Viewer Portlet

The Java Portlet Specification V 2.0 (JSR 286) defines something called a render parameter that is provided to the portlets for each request. For example, when the user presses the browser's reload button, the portlet gets the same render parameters again and can render the same view. This means that the portlet does not need to store this navigational state information in the session any longer

The fully qualified name of the public render parameter that is supported by the JSR 286 Web content viewer is http://www.ibm.com/xmlns/prod/datatype/content:context

Because you might have many public and private render parameters that you need to store in the URL, you need to make sure that the URLs don't get too long. WebSphere Portal does this by zip-encoding that part of the URL

If a specific parameter gets too large, it is stored in the session and only the reference key is stored in the URL. This helps to keep the URL below the 2K size limit enforced by many browsers or other HTTP infrastructure components, such as proxies.

The disadvantage of this solution is that you are now no longer able to create these parameters by hand because of the encoding. Therefore, Portal provides you with the above mechanism of adding a simple URI at the end of a portal URL

Reset WCM_GLOBAL_CONTEXT when switching portal pages

JSR-286 based Web Content Viewer portlet does not make use of the WCM_GLOBAL_CONTEXT query parameter but instead uses a public render parameter as defined by the portlet standard to holds its context information. By default all public render parameters are shared across pages in Portal.

So what happens is that when you select the link to the item on the first page a public render parameter is set that basically tells the JSR-286 Web Content Viewer portlet, that was configured to listen to broadcast links from other portlets, to renders the content item that was set in the public render parameter. When you then switch to the next page all public render parameter are maintained and also available on the second page. Thus the web content viewer on the second page renders the content item set in the public render parameter.

To solve this you can either:

• Set the parameter "param.sharing.scope" on both pages to a unique value. This parameter is documented here http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/topic/com.ibm.wp.ent.doc_v6101/dev/pltcom_pubrndrprm.html and controls how public render parameter for JSR portlet are scope. To have a unique scoping simply set the value of this parameter to any arbitrary but unique value.
• Use web content pages instead of "normal" portal pages. As for web content pages the param.sharing.scope parameter is set to a unique value automatically during page creation

Note: 

If you want reset all render state(private or public render parameter) of all JSR portlets when selecting page from navigation links(generated from theme) with use of the following

<portal-navigation:urlGeneration keepNavigationalState="false"> 

Click Here( Infocenter) to see more details on JSP tag 

URI Resolver Framework 

In the newer JSR 286 viewer, you use the URI resolver framework in WebSphere Portal to address pages and content items from external systems. The URI resolver framework is a generic resolver framework that can also be leveraged for custom URI schemes. Web Content Management defines the schema wcm: as follows:
wcm:path:LIBRARY/SITE_AREA_PATH/CONTENT [[& page=unique_name | object_id] &mapping=mapping | &current=true]

means that you provide the path to the content and then optionally provide one of the following:

• A target page, using either the unique name of the page or its object ID.
• A URL mapping.
• The current page selected in the URL to use before the URI.

If you don't provide any of the above, WebSphere Portal automatically tries to find the right page. This works only if you’re using the Web Content Pages, where you map a Web Content Management site area to a portal page so that WebSphere Portal is aware of the relationship.
So, how do you get a complete URL now? You have a couple of different options:

• Address the WebSphere Portal resolver framework directly via /wps/poc or /wps/mypoc.
• Use any URL for WebSphere Portal that is known by the external application.

Following are some sample URLs:

• Addressing the portal resolver framework directly:

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

This URL tells the portal to render the content item with the library path Web Content/NewsUS/News1. WebSphere Portal will look up the Web Content Page that is mapped to the NewsUS site area (Company News/US), redirect to that page, and set the context of that page to the content item library path.

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

This URL tells WebSphere Portal to render the content item the same way as the previous URL, but instead of doing the dynamic page look-up to do a redirect to the page /Products/Cars, which is mapped to the URL /coolCars

The complete syntax of these kind URL's is:
/wps/[my]poc[/vp]?urile=wcm:path:[path to WCM content][&page=[unique name or ID] | &mapping=[url mapping] | &current=true]

• poc for un-authenticated access
• mypoc for authenticated access
• To address a virtual portal append the VP mapping. E.g.:
  /wps/mypoc/myvp
  /wps/poc/myvp
• Alternatively to using the poc servlet you can also append the "urile" parameter on any Portal URL including URL that contain URL mappings e.g to address a specific portal page defined by the url mapping use /wps/[my]portal[/url mapping]?current=true&urile=wcm:path:[path to WCM content]
• To address a specific portal page use one of the following parameters exclusively:
• page=unique name or ID of page
• mapping=url mapping label
• current=true (To stay on the current page)
• To leverage dynamic WCM page lookup: ommit any page parameter

There must be at least one JSR 286 web content viewer portlet on the target page and it must be configured to receive links from Other portlets and this portlet,

Note: You actually have two choices: you can specify "uri" or "urile." The difference is that if you use the uri scheme, you need to follow the URI encoding rules in addition the URL encoding rules, so the URL:

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




would look like this using the "uri" scheme:

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