Your portal and web content management system should play well together
If you've been working with IBM® Lotus® Web Content Management and tried to get your content rendered in IBM WebSphere® Portal, you might have had a difficult time deciding where to define your site structure. Up to now, you have basically had two options:
- Define the site structure in both WebSphere Portal and Lotus Web Content Management, thus duplicating each WebSphere Portal page with a newly created Lotus Web Content Management site area for that page.
- Create only a stub page in WebSphere Portal and do all the rest in Lotus Web Content Management via the site areas.
Neither of these options is exactly optimal. Besides being very tedious and error prone, the first option requires that you put the Web content rendering portlets on each page and configure them to point to the current site area. Creating links between different pages requires a lot of hardcoded customization in each of the Web content rendering portlets to get it to dispatch to the right place. The second alternative isn't all that attractive either. Because WebSphere Portal is no longer aware of the navigation structure, you lose basic portal benefits.
But there is hope! You can now have a fully integrated solution in which WebSphere Portal V6.1 knows about your Lotus Web Content Management V6.1 content without requiring you to make hundreds of clicks to set up your site. The magic is contained in Web content pages and in new Web content rendering portlets.
The first step toward a tighter integration between Lotus Web Content Management and WebSphere Portal is to make WebSphere Portal aware of your Lotus Web Content Management content. With new Web content pages, you can now attach a Lotus Web Content Management site area to a portal page. This new concept is part of the Lotus Web Content Management Rendering Portlet catalog shipment .
Here is how you would attach such a site area to a page in the UI:
- In WebSphere Portal, create a new Web content page via the Manage Pages portlet (Figure 1).
Figure 1. Manage Pages portlet with new button to add Web Content pages
- On the new page, you have two new Web Content Options: you can select a Lotus
Web Content Management folder or you can select a shared page to use as a template (Figure 2).
Figure 2. Creating a Web Content Page
Let's try the first option. Select a Lotus Web Content Management folder first by clicking on Select and then browse to the site area to which you want to attach to your new page (Figure 3).
Figure 3. Mapping a Web Content page to a site area
- Next, select a template page that already has the theme, theme policy, and
portlets defined on it that you want to use (Figure 4).
Figure 4. Select template page for the new Web Content page
And you're done. Your new page is complete.
So what do you gain by doing this and telling WebSphere Portal about the Lotus Web Content Management site area? Actually, you gain a lot.
For example, you no longer need to configure the portlet with a page to dispatch when clicking a link to an item outside the current site area. In most cases, you also no longer need to configure the portlets, since they will pick up the page context automatically and render the default content item of that site area. One thing to be aware of is that only the new Web Content Management rendering portlets that are part of the Rendering Portlet catalog shipment support this functionality.
This new capability enables you to separate the navigation of your site from the content that you have. You now have just one place where you define your site structure: in WebSphere Portal via the means for creating pages. By making the link between a portal page and a site area or content folder, you define the bridge between the site structure and the content on the page. Using Lotus Web Content Management, you can now group the content according to what makes most sense for the content, independent of how the site structure appears for the user. Now that Lotus Web Content Management pages are completely inside WebSphere Portal like any other portal page, you can easily leverage additional features, like attaching a friendly name to the page that will display in the URL, and so on.
Let's go back and try the second new Web Content Option on the Page Properties panel (Figure 4), which is the ability to select a template page.
Moving to the new paradigm of defining the site structure in WebSphere Portal also means that content authors might now need to create portal pages and attach them with their Web Content Management content. To make this as simple as possible for your content authors, you can now define a set of template pages, which are regular portal pages located under a special label (or page). On these template pages, you can define themes and skins, load portlets on them, and even pre-configure them. A content author can choose a template to work with and all the settings from the template page are copied for the new page (Figure 5).
Figure 5. Creating Web Content pages from templates pages
The content author sets the page name, selects the template page, selects the Web Content Management site area, and the page is done (Figure 6).
Figure 6. New Web Content page
The theme and skins are pre-defined and the page already contains two pre-configured portlets; the one on the left points to a component listing all items in the current site area, and the one on the right displays the items. The page is now also ready for interaction. If you click on a link in the left portlet, the right portlet will change and display the selected content. If you click on a link in the right portlet that points to a content item outside of this site area, WebSphere Portal will perform a lookup of the portal page linked to that site area, automatically dispatch to that site area, and select the content item in the link as context of that new page.
You get all of that by simply clicking New Web Content Page (Figure 1), adding a page name, selecting a Web Content Management site area and a template page.
The new Web Content Rendering portlets
As you learned in the previous section, the new Web Content Rendering portlet (also called Web Content View portlet) plays a significant role in enabling you to better integrate content with WebSphere Portal. However, these portlets offer even more benefits. Now based on the new JSR 286 Java Portlet Specification V2.0 standard, these new portlets implement the new common OneUI look and feel shared by IBM Lotus products. Functionality-wise the new rendering portlet provides these benefits beyond the dynamic page context explained earlier:
-
Re-worked UI for ease of use
The new UI now only displays options that make sense for the currently selected content type (Figure 7). It also hides the more advanced settings under an Advanced Options tab and lets you collapse sections. Each section also has its own help that can be easily accessed via the Help button on the right side.
Figure 7. Updated UI of the Web Content Viewer portlet
-
Session-less rendering
The new rendering portlet no longer requires a session to store its data, but instead uses render parameters that are encoded in the URL. The portlet no longer requires anonymous Web sites to create sessions on the server and thus scales much better.
-
Locking of preferences in config mode
The portal administrator can now lock settings in the portlet config mode to prevent content authors from changing one of those settings in the edit_defaults mode (Figure 8).
Figure 8. Lock settings
In Figure 8, the categories have been pre-set in the config mode and the administrator has locked the setting by clicking on the lock icon. If you now go to the edit_defaults mode, you would see something similar to Figure 9. The categories are now grayed out and not changeable by the user.
Figure 9. Locked settings
- Caching content inside WebSphere Portal
Another performance improvement is that the content of the Web Content Management portlet can now be cached in the portal fragment cache. The cache settings can be configured in the portlet settings section (Figure 10). You can also have the cache entry shared or non-shared across users. Having the option to share the cache entry for content items that are the same across users is a huge benefit, especially if this can be done on a frequently accessed landing page.
Figure 10. New caching options in the Web Content Viewer portlet
- Leveraging the Eclipse plug-in model for extensions
The extension for changing the path to the content item that gets rendered (the context processor) is now an Eclipse plug-in that can be hosted in its own WAR file and deployed independent from WebSphere Portal. You can now also easily manage which context process should be applied to which rendering portlet via the configuration panel (Figure 11).
Figure 11. Advanced options for select extensions to be applied before rendering the content
- Site analytics log
Since the rendering portlet is really a proxy that dispatches to the Web Content Management system for rendering, it does not help much to just get a generic entry in the site analytics log file that indicates that the portlet was called. What would be more helpful is to see which content item has been rendered so that you can tell which items are more popular than others. To support this, the new rendering portlet now creates an additional site analytics log entry enabling you to identify the content item being rendered.
- Customized error messages
You can now add your own custom error JSP that gets displayed in case an error occurred during rendering. You can set a new config parameter on the rendering portlet pointing to your JSP, but it currently needs to be in the WAR file of the rendering portlet.
- Enable resource bundles for localized portlet titles
You can now point a portlet to a resource bundle for displaying its title in a localized manner (Figure 12). The class name of the resource bundle must be accessible via the classpath and have the title in it with the key "javax.portlet.title."
Figure 12. Point to an external resource bundle for rendering the portlet title
As you can see, the new portlets provides a lot of additional features. Of course, all the options of the previous portlet are also supported, so you should be able to move easily from your current configuration to use the new portlets.
One inconvenience is with the inline editing use case; you now get redirected to a different page where you can perform the inline editing, but you need to manually navigate back to the page where you started the inline editing. Alternatively, you can specify a popup window where you do the authoring, but when you finish and close the popup, you need to reload the page to get the updated view. (This is expected to be resolved in a forthcoming update.)
With WebSphere Portal V6.1.0.1, you also get the new seedlist 1.0 format for Web Content Management. This format is now based on ATOM and enables filtering of the access control information by the client. It is turned off per default, but is simple to turn on. The new seedlist format also now includes the new POC URIs that address the content directly. Thus, if you click on such a link in the search center and you have the above mentioned Web content pages set up, then WebSphere Portal will automatically figure out the page responsible for rendering the content item, select that page, and set the page context to that content item. Thus, you will see the selected content item on the page on which you would normally see that item, including all the other portlets that should be on this page.
The Web Content Management Rendering Portlet catalog shipment addresses many of the issues that those trying to integrate WebSphere Portal and Lotus Web Content Management have faced up to now. You now have one place where you define your site structure -- WebSphere Portal -- making it very easy now to create new Web content pages and have everything work in an integrated manner, including the ability to search. On top of that, the new portlets offer better performance and lots of new features!
Learn
-
JSR 286: Portlet Specification 2.0
-
IBM WebSphere Portal product information
-
IBM Lotus Web Content
Management product information
-
IBM WebSphere Portal
and Lotus Web Content Management Information Center
-
IBM
developerWorks WebSphere
-
IBM
developerWorks Lotus
Get products and technologies
Discuss
Stefan Hepper is a software architect on the WebSphere Portal team at the IBM Silicon Valley Lab in the U.S. He is responsible for rendering WCM content in portal and the convergence of WCM and portal. Previously, he was leading the Java Portlet standards JSR 286 and 168. He has conducted lectures at international conferences, published papers, filed patents, and is a co-author of the book Pervasive Computing (Addison-Wesley 2001).
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
