Datasheet

Portlet Customization Declarations
This defines a custom portlet mode called MY_MODE. Of course, whenever an application defines a cus-
tom portlet mode, it must not only be available through the targeted portal server, but also needs to have
portlets that actually use the mode (while programming defensively enough to avoid breaking in unsup-
ported portal servers).
<custom-portlet-mode>
<description xml:lang=”EN”>Custom portlet mode MY_MODE</description>
<portlet-mode>MY_MODE</portlet-mode>
</custom-portlet-mode>
LEFT-SIDE is defined here as a custom window state. Just as with custom portlet modes, custom win-
dow states can cause problems with your application’s portability. In addition, like custom portlet
modes, you can define multiples in the same application, but they must have unique names.
<custom-window-state>
<description xml:lang=”EN”>Docked into the left side</description>
<window-state>LEFT-SIDE</window-state>
</custom-window-state>
User Attributes and Security Constraints
The following code defines a user attribute called user.business-info.online.email that refers
to a user’s business e-mail address. Typically, these attributes are mapping from the portal server’s per-
sonalization database, which is why using standard names can ease the integration of user attributes.
Developers should use user attributes from the W3C P3P standard, as specified in the Portlet API. This
should ensure that they are unique (as required in the XML Schema for the
portlet.xml) and reusable
(standards-compliant).
<user-attribute>
<description>P3P attribute for work e-mail address</description>
<name>user.business-info.online.email</name>
</user-attribute>
This is the security constraint for this portlet application. It lists the name of the portlet, ExamplePortlet,
and also specifies a user data constraint of
INTEGRAL. User data constraints define the guarantees specify-
ing how the portlet communicates with the user. Three values are allowed here:
NONE, INTEGRAL, and
CONFIDENTIAL. NONE means that there are no guarantees about the transmission of data between the
portlet application and the user.
INTEGRAL specifies that the data must be checked to ensure that it has not
been manipulated (no added or removed information from the message).
CONFIDENTIAL requires that the
data cannot be read by anyone other than the user. Typically, Secure Sockets Layer (SSL) is used to pro-
vide both
INTEGRAL and CONFIDENTIAL constraints.
<security-constraint>
<portlet-collection>
<portlet-name>ExamplePortlet</portlet-name>
</portlet-collection>
<user-data-constraint>
<transport-guarantee>INTEGRAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
31
The Java Portlet API (JSR 168)
04 469513 Ch01.qxd 1/16/04 11:04 AM Page 31