Getting to Know the Browser: Working with Client Profile Information in Portlets
WebSphere Portal supports the integration of data from disparate systems in order to manage and deliver it to clients. How users experience this content continues to vary depending on the user’s browser. To assist in content delivery, WebSphere Portal provides an API named “CC/PP” that presents a profile of the user’s browser through a request attribute.
To work with this profile you will need to import two objects:
javax.ccpp.Attribute and javax.ccpp.Profile
As an example consider the following:
Profile clientProfile = (Profile) portletRequest.getAttribute(PortletRequest.CCPP_PROFILE);
// By getting an instance of a Profile named clientProfile we can then extract
// one of the members of the profile such as manufacturer of the browser, Vendor.
String vendor null;
if (clientProfile != null) {
Attribute attribute = clientProfile.getAttribute(“Vendor”);
if (attribute != null) {
vendor = attribute.toString();
}
}
// Now that you know the Vendor you can do something interesting.
What are some other members of the profile?
The browser name, version, markup supported, style sheet support, etc.
You may ask why we shouldn’t handle this in JavaScript? One reason I can think of right away is mobile access.
The volume of information to push to the mobile browser can be significantly reduced by determining the markup (JSP) before rendering the page for the client.
Mind Numbing Moments
When ever I advise someone on applying packs and fixes to IBM WebSphere Portal I ALWAYS say they must read every line of the documentation and follow each of the linked documents until they have determined the precise requirements for their environment. Of course sometimes I fail to follow my own advise.
Such was the case today. I am installing a new development environment for our dev team. Because I feel it is imperative that the platform for which they are developing is current, I decided to apply the most current and recommended fix packs and fixes. I scanned the very familiar text of the relevant pages and quickly surmised that the process was the same as before. 
One recent change to the site proved to be a bonus. There is now a wizard interface to guide the selection of the recommended packs and fixes. I dutifully downloaded the artifacts for the WebSphere Application Server, the WebSphere Portal Server, and the required update installers for each.
Next, as usual, I installed the WAS fix using it’s installer and then, using the HealthChecker tool for the portal, I confirmed that the platform was ready for the portal pack and fixes. The install of the fix pack failed. It was a message not unfamiliar to me. In a nutshell, the log showed that the user did not have permission to extract the archive for WP_PTF_7002. Well, I thought, maybe I should log on to Windows as the portal admin. While it is not normal to see this error on Windows (very common on Linux and Unix) I assumed that there were indeed some ownership issues on Windows Server 2008 that I had overlooked.
The operative words in this monolog are ‘quickly’, ‘surmised’, and ‘assumed’. After making ownership changes to the entire folder structure I tried again; I failed. I dove into the DeveloperWorks forums. I scanned the web. No luck seemed to be coming my way. I almost reached out to a friend at IBM to ask if he had seen this problem. And then I was struck by a thought, “What if I contact my friend and he points out something in the documentation I had overlooked.”
With reluctance only marginally overcome by the potential of real embarrassment I read (notice I did not say re-read) the docs. And there it was: a simple requirement to provide values to WASPassword and PortalAdminPWD in the wkplc.properties file. While I am inclined to quibble about the necessity or even the desirability of this, I have to admit that it was a simple overlooked requirement that cost me an hour of frustration.
Lesson learned: surmise less and read more.
Web Experience Factory 8 Beta One
This beta will be a welcome experience for developers seeking to offer a nimble client side experience. Clearly the direction of IBM is to increase the adoption of client side aggregation pioneered in the WebSphere Portal 6.1.5 update, refined in WebSphere Portal 7.0, and now, further evolved in WebSphere Portal 8 Beta 2.
First things first, get your hands on the beta by going to http://www-10.lotus.com/ldd/pfwiki.nsf/dx/08072009024448PMWEBPZ3.htm
You will probably want to get your hands on the portal as well and my last post describes a Windows install if you are so inclined. (Don’t worry Linux geeks, there’s a mention of the Linux VMWare offering as well.)
What will you find when you begin to explore the new features? Here’s a brief laundry list with a promise from me to tell more shortly:
- Support for client side mobile web UI architecture
- Easier implementation of Dojo mobile
- Builders to integrate Filenet and Sharepoint
Interestingly, some of the features that focus on mobility appear to be ‘exclusive’; If you want to develop a multi-channel application you may find “the server-side page based mobile development support available in Web Experience Factory 7.0.1 to[sic] be more suitable for such development.”
Check out http://www-10.lotus.com/ldd/pfwiki.nsf/dx/IBM_Web_Experience_Factory_8.0_Beta_One_Overview#Dojo+Mobile+and+Data+layout+templates for more details.
Taking Notez - Island Pond Consulting 