Personalization and User Attributes

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