281 CHAPTER 11 Personalization and User Attributes B ECAUSE A PORTLET IS generally a minor part of a larger application (the portal), most of the time it will have a strictly limited canvas on which to present its infor- mation. So it is vital that the portlet should make the best possible use of this. A portlet can acquire a considerable body of information with which to tailor its contents to specific users, and in this chapter we discuss how to take advantage of that. Making a Good Impression Everybody wants to be remembered. The portlet specification makes allowance for this by suggesting that portals should acquire and then provide to their portlets a set of personal information. This is provided to the portlet in the PortletRequest so that it is available to render and action methods. No mechanism is provided to the portlet to alter this information—it is under the direct control of the portlet container. The idea is that a portlet will be able to greet users by name and access their personal information silently to avoid the need for tedious form filling. For exam- ple, an e-commerce portlet might select the user’s home address from the user attributes when dispatching an order. An e-mail portlet would probably make use of the name information. We Know Who You Are The portal may know the user because they have just logged in—or it may recall their previous visit to the site by registering a cookie. If the user has never visited the site before and they are not logged in, then no user attribute information is available to the portlet. The attributes are provided as “key value pairs” so the specification has sen- sibly selected the standard Map interface from the collection classes as the means of accessing them. This map is obtained from the conventional attributes by means of the predefined key PortletRequest.USER_INFO . 2840ch11.qxd 7/13/04 12:44 PM Page 281 Download at Boykma.Com Chapter 11 282 Quite an array of attributes may be available to you (if you try to get a value from the map using an attribute for which there is no information, null will be returned). These are organized in a hierarchy modeled after the usual Java attribute key convention and grouped into the user’s immediate personal information and their (personal and business) contact details. The hierarchy is based on the Platform for Privacy Preferences (P3P) specification from the W3C, which is available in full at www.w3.org/TR/2004/WD-P3P11-20040427/ . The attributes available are identical to those offered by the Web Services for Remote Portlets (WSRP) standard (discussed in the next chapter), making it straightforward to make attribute-driven portlets available as services. An exhaus- tive list of the keys recommended by the standard follows. The user’s immediate personal information: user.bdate user.gender user.employer user.department user.jobtitle The user’s identifying information: user.name.prefix user.name.given user.name.family user.name.middle user.name.suffix user.name.nickName The user’s personal address information: user.home-info.postal.name user.home-info.postal.street user.home-info.postal.city user.home-info.postal.stateprov user.home-info.postal.postalcode user.home-info.postal.country user.home-info.postal.organization The user’s personal telephone details: user.home-info.telecom.telephone.intcode user.home-info.telecom.telephone.loccode user.home-info.telecom.telephone.number user.home-info.telecom.telephone.ext user.home-info.telecom.telephone.comment 2840ch11.qxd 7/13/04 12:44 PM Page 282 Download at Boykma.Com Personalization and User Attributes 283 The user’s personal fax details: user.home-info.telecom.fax.intcode user.home-info.telecom.fax.loccode user.home-info.telecom.fax.number user.home-info.telecom.fax.ext user.home-info.telecom.fax.comment The user’s personal mobile phone details: user.home-info.telecom.mobile.intcode user.home-info.telecom.mobile.loccode user.home-info.telecom.mobile.number user.home-info.telecom.mobile.ext user.home-info.telecom.mobile.comment The user’s personal pager details: user.home-info.telecom.pager.intcode user.home-info.telecom.pager.loccode user.home-info.telecom.pager.number user.home-info.telecom.pager.ext user.home-info.telecom.pager.comment The user’s personal e-mail and web site details: user.home-info.online.email user.home-info.online.uri The user’s business address: user.business-info.postal.name user.business-info.postal.street user.business-info.postal.city user.business-info.postal.stateprov user.business-info.postal.postalcode user.business-info.postal.country user.business-info.postal.organization The user’s business telephone details: user.business-info.telecom.telephone.intcode user.business-info.telecom.telephone.loccode user.business-info.telecom.telephone.number user.business-info.telecom.telephone.ext user.business-info.telecom.telephone.comment 2840ch11.qxd 7/13/04 12:44 PM Page 283 Download at Boykma.Com Chapter 11 284 The user’s business fax details: user.business-info.telecom.fax.intcode user.business-info.telecom.fax.loccode user.business-info.telecom.fax.number user.business-info.telecom.fax.ext user.business-info.telecom.fax.comment The user’s business mobile phone details: user.business-info.telecom.mobile.intcode user.business-info.telecom.mobile.loccode user.business-info.telecom.mobile.number user.business-info.telecom.mobile.ext user.business-info.telecom.mobile.comment The user’s business pager details: user.business-info.telecom.pager.intcode user.business-info.telecom.pager.loccode user.business-info.telecom.pager.number user.business-info.telecom.pager.ext user.business-info.telecom.pager.comment And finally, the user’s professional e-mail address and web site: user.business-info.online.email user.business-info.online.uri Problems with User Attributes The main problem with user attributes is that they won’t necessarily be available to your portlet. Although support for them is a mandatory part of the JSR 168 specification, all of the individual attributes are optional, so the requirement has very little real force. As a result, your portal may support user attributes in name alone. CAUTION At the time of writing, Pluto and most other open source portlet containers do not support user attributes. 2840ch11.qxd 7/13/04 12:44 PM Page 284 Download at Boykma.Com Personalization and User Attributes 285 Assuming that user attributes are supported to some extent, you are given only the rather lukewarm assurance that the attributes listed in the previous section are “recommended.” If your chosen portal adds other attributes to that list, there is no reason to believe that they will be available in other portals, so you must be careful not to make your portal reliant on them unless you can be certain that it will not be used outside that environment. Let’s suppose for the sake of argument that all of the listed attributes are sup- ported by your portal. A user may well balk at entering nearly 70 items of very personal information. This point may be less of an issue in an intranet environment where you will often have all of this information at hand in a directory service of some sort—but if you are operating a portal for external users, you should probably not make the registering of all of this information mandatory for use of the site. Discounting all the rest of these issues, if the user is not logged in to the portal, there may be no way to associate that user with the appropriate attributes! The attributes are not very comprehensive—plenty of users will have more than one mobile phone number, and no pager at all. But it may be that you will want to make use of an external directory service such as Lightweight Directory Access Protocol (LDAP) in preference to working within the limitations of the user attributes anyway. CAUTION The specification explicitly states that user information is outside its scope and that the user-attributes mechanism will probably be deprecated in favor of a future, more considered mechanism. Finally, we note that the specification requires the attribute associated with the user’s birth date to be “an integer representing the time in milliseconds since 1970, 00:00:00 GMT.” We are concerned that the behavior for dates prior to 1970 has not been defined. Perhaps the obvious solution is to use a negative number, but that which is not defined tends to get interpreted differently by different imple- mentations. 1970 isn’t that long ago—while Jeff clears it nicely with eight years to spare, Dave scrapes by with only two—and Dave’s brother falls firmly into the problem range. Note that since the standard requires the value part of each attribute to be a String object, the question of rolling over into the next epoch that is an issue with fixed-size time fields does not arise. Accessing the Attributes Despite our concerns with the implementation of user attributes, they raise no concerns for the developer from an ease-of-use perspective. 2840ch11.qxd 7/13/04 12:44 PM Page 285 Download at Boykma.Com Chapter 11 286 A mapping of the attribute names (as strings) to their assigned values can be retrieved from the portlet requests using the getAttributes() method: Map userAttributes = request.getAttribute(PortletRequest.USER_INFO); The retrieved reference may be null if user attributes are unsupported or unavailable; otherwise, a Map instance will be provided. The attribute values are then extracted to form the map: String surname = (String) userAttributes.get("user.name.family"); The reference returned will be null if the requested attribute is unsupported or unavailable. To illustrate this process, let’s build a simple portlet that looks for and (if found) displays a set of user attributes: package com.portalbook.portlets.custom; import java.io.IOException; import java.util.Iterator; import java.util.Map; import javax.portlet.GenericPortlet; import javax.portlet.PortletException; import javax.portlet.RenderRequest; import javax.portlet.RenderResponse; public class UAPortlet extends GenericPortlet { protected void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException { Map ua = (Map) request.getAttribute(RenderRequest.USER_INFO); response.setContentType("text/html"); if ((ua == null) || !ua.keySet().iterator().hasNext()) { response.getWriter().write( "<b>No user attributes could be found</b>"); } else { Iterator i = ua.keySet().iterator(); response.getWriter().write("<table>"); while (i.hasNext()) { 2840ch11.qxd 7/13/04 12:44 PM Page 286 Download at Boykma.Com Personalization and User Attributes 287 Figure 11-1. User attributes revealed String attributeName = (String) i.next(); String attributeValue = (String) ua.get(attributeName); writeAttributeRow(response, attributeName, attributeValue); } response.getWriter().write("</table>"); } } private void writeAttributeRow(RenderResponse response, String name, String value) throws IOException { StringBuffer buffer = new StringBuffer("<tr><td>"); buffer.append(name); buffer.append("</td><td><b>"); buffer.append(value); buffer.append("</b></td></tr>"); response.getWriter().write(buffer.toString()); } } Figure 11-1 shows the output of the portlet when running. In order to access the user attributes, the portlet has to tell the portal that it’s interested in the information. It achieves this by adding <user-attribute> elements at the <portlet-app> level of the portlet.xml file. Here are the appropriate entries for our example: <portlet-app xmlns=http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd version="1.0" 2840ch11.qxd 7/13/04 12:44 PM Page 287 Download at Boykma.Com Chapter 11 288 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation= "http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd" > <portlet> <description>Portlet Attribute Lister</description> <!--The rest of the portlet definition has been omitted --> </portlet> <user-attribute> <description>User Given Name</description> <name>user.name.given</name> </user-attribute> <user-attribute> <description>User Title</description> <name>user.name.prefix</name> </user-attribute> <user-attribute> <description>User Name Suffix</description> <name>user.name.suffix</name> </user-attribute> <user-attribute> <description>User Family Name</description> <name>user.name.family</name> </user-attribute> <user-attribute> <description>User Middle Name</description> <name>user.name.middle</name> </user-attribute> <user-attribute> <description>User Employer Name</description> <name>user.employer</name> </user-attribute> <user-attribute> <description>User Department Name</description> <name>user.department</name> </user-attribute> <user-attribute> <description>User Job Title</description> <name>user.jobtitle</name> </user-attribute> </portlet-app> 2840ch11.qxd 7/13/04 12:44 PM Page 288 Download at Boykma.Com Personalization and User Attributes 289 Making Choices As we discussed in the introduction to this chapter, your portlet needs to use its screen real estate wisely. Since different users will have different requirements for your portlet, this requires you to adapt the portlet’s display dynamically to respond to the current user. The two main sources of information available to your portlet will be the login information and the user attributes. It is important to remember the distinction between the two, however. The login information is reliable. The portal will have obtained it by secure means, and if a Principal is provided, your portlet will be able to verify for itself that this is correct (often this is overkill, since within the portal server the portlet is subject to any of the security flaws in the container). On the other hand, the user attributes come with no guarantee. The user might be using the same browser (and hence cookies) as some other user, or the user may have lied or misunderstood when filling in the registration form. Do not assume that because the user’s name is available from the user attributes that these attributes are correct. When deciding how to use this information, you will need to consider the business requirements first, and only then encode them in your application. Let’s discuss two approaches to this: the traditional “hardcoded” technique and the “softcoded” rules-based approach. The Traditional Approach The traditional approach to laying out the display is simply to write code that branches depending on the status of various variables. For example, here is a code fragment that might be used to determine what to render in an online trading portlet: protected void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException { Map ua = (Map) request.getAttribute(RenderRequest.USER_INFO); response.setContentType("text/html"); if (ua == null) { renderDefaultPortlet(request, response); } else { if (request.isUserInRole(ADMINISTRATOR_ROLE)) { 2840ch11.qxd 7/13/04 12:44 PM Page 289 Download at Boykma.Com Chapter 11 290 renderAdministratorTools(request, response); } if (request.IsUserInRole(KEY_ACCOUNT_MANAGER_ROLE)) { renderKAMTools(); renderCustomerTools(); } else if (request.IsUserInRole(SUPPORT_ROLE)) { renderSupportTools(); renderCustomerTools(); } else if (request.IsUserInRole(HELPDESK_ROLE)) { renderCustomerTools(); renderHelpdeskTools(); } if (request.IsUserInRole(CUSTOMER_ROLE)) { if (customerNameAvailable(ua)) { renderCustomerName(ua); } renderCustomerTools(); } else { renderDefaultPortlet(request, response); } } } While this code is sensible, it is not easy to follow. The number of conditions involved makes it difficult to determine whether all of the decisions made are correct. For example, will staff be members of the customer group anyway? If so, then we risk rendering the customer tools twice for some administrative users. We can hide some of this functionality inside the rendering methods, but this approach won’t necessarily shield us from the difficulty of determining whether the application is doing the right thing from a business point of view. 2840ch11.qxd 7/13/04 12:44 PM Page 290 Download at Boykma.Com [...]... shown in Figure 11-2 Download at Boykma.Com 291 2840ch11.qxd 7/13/04 12:44 PM Page 292 Chapter 11 User Attributes Portal Roles Portlet Business Rules Web Page Figure 11-2 Bringing rules into the display logic The information available to the system, such as the user attributes, the user s role memberships, and other information not shown such as the window state, is combined with the business rules to... 2840ch11.qxd 7/13/04 12:44 PM Page 293 Personalization and User Attributes Helpdesk Helpdesk,Customer Customer Customer user general If a manager decides that the helpdesk should only deal with the simplest queries and have no access to customers’...2840ch11.qxd 7/13/04 12:44 PM Page 291 Personalization and User Attributes Adding the three standard window states available to a portlet into this already complex situation makes things very much worse Clearly an alternative approach is required Rules-Based Approaches... Jess library from Sandia National Laboratories, which can be downloaded from http://herzberg.ca.sandia.gov/jess/ (Jess requires a license for commercial uses) The open source tool DROOLS is available from http://drools.org/, and this implements the JSR 94 standard Download at Boykma.Com 293 2840ch11.qxd 7/13/04 12:44 PM Page 294 Chapter 11 Summary In this chapter we looked at the user attribute information... people might think and speak about the business requirements for the portlet—that a key account manager should have access to the customer tools (perhaps to place bids on behalf of a client), but that the administrator who is concerned with determining who is on the helpdesk and who is an account manager and so forth should not This technique of rules-based programming is well established, and free tools... business semantics module and integrating it into your code are too extensive to be covered in depth in this chapter, several resources are available to you if you’re interested in pursuing this technique There is a standard for integrating rules-based systems with Java, JSR 94, which is available from the Java Community Process web site (www.jcp.org/en/jsr/ detail?id=94), and a reference implementation... deal of branching dependent on business requirements, you are essentially coding business “rules” into your system For example, the very first condition we encounter states in essence is Unidentified users should see the default portlet Taking the remaining rules in our example, we end up with a set of quite simple statements about how the application should behave: Administrators should see the administrator... implements the JSR 94 standard Download at Boykma.Com 293 2840ch11.qxd 7/13/04 12:44 PM Page 294 Chapter 11 Summary In this chapter we looked at the user attribute information available to an application, and described two techniques for using this information to present a personalized view of your portlet In the next chapter, we discuss how you can make your portlet available as a service so that it can . recommended by the standard follows. The user s immediate personal information: user. bdate user. gender user. employer user. department user. jobtitle The user s identifying. information: user. name.prefix user. name.given user. name.family user. name.middle user. name.suffix user. name.nickName The user s personal address information: user. home-info.postal.name