PortletPreferences and PortletSession
The specification defines a few different methods that involve storing user information, either permanently or for the length of a client's session. The two most important are PortletPreferences and PortletSession.
PortletPreferences is an object that can be used to store persistent data for a portlet user. PortletPreferences stores pairs of names and values that are retrievable during the render phase through a getValue method. In processAction, values can be set and saved through the setValue and store methods, respectively. Optionally, you may include a PreferencesValidator object to check values prior to persisting preferences (via it's validate method). Default preference values may be specified in a portlet's descriptor file.
In servlet programming, HttpSession lets you to store session-specific data. Additionally, the Java Portlet Specification defines the PortletSession interface for storing information within a user's session. PortletSession identifies two scopes, PORTLET_SCOPE and APPLICATION_SCOPE. In portlet session scope, you can store data specific to a single portlet instance, within a user's session. The application session scope can store data across all of a user's portlets within the same session.
Other Important Features
Below is a list of some of the additional features defined by the Java Portlet Specification.
- An include mechanism for incorporating servlets and JSP pages into your portlets. A PortletRequestDistpacher accomplishes this, much the same way a RequestDispatcher would in the servlet world. This allows your portlet methods to act as controllers, redirecting work to specified servlets and JSPs.
- A way to create non-standard portlet extensions, such as custom portlet modes. The PortalContext object can be used to query information about a portal vendors supported extensions. Then, portlet developers could decide if they would like to take advantage of any of those non-standard features.
- A taglib is provided for use in a portlet's JSP pages. These tags provide a way to construct the URLs a portlet needs to refer back to itself. The taglib also provides a way to include all the necessary portlet-specific classes a JSP will need.
- The ability to manage portlet security, like designating a portlet to run only over HTTPS.
- A Method for accessing ResourceBundles for portlet localization.
- The option of declaratively specifying an expiration cache for a portlet
Also, when discussing the Java Portlet Specification it is relevant to mention its relationship to another standard, the Web Services for Remote Portlets, or WSRP. WSRP is a standard for accessing content generated by remote portlets, possibly portlets using a technology other than J2EE. Though separate specifications, the Java Portlet Specification and WSRP were each developed with the other's standards in mind. As a result, the two specifications share many of the same concepts, like portlet modes and window states, allowing a portal to use both quite effectively.
Packaging a Java Portlet
The Java Portlet Specification allows a portlet or portlets to be packaged as a .war file for deployment to a J2EE application server. Just like a .war file used to deploy a typical J2EE web application, it contains a WEB-INF/web.xml file to configure the application context. However, with a portlet application, the WEB-INF folder must also contain a portlet.xml file. The portlet.xml file is a descriptor file, containing configuration details about all bundled portlets in the .war file.
The following listing shows a simple example of a portlet.xml file. Note how many of the previously-described constructs (portlet mode, preferences, etc.) are defined in this file.
A portlet.xml example
<portlet-app>
<portlet>
<portlet-name>MyPortlet</portlet-name>
<portlet-class>com.abc.portlet.MyPortlet</portlet-class>
<init-param> --Init param, available in portlet's PortletConfig instance.
<name>view-to-present
<value>/portlet/MyPortlet/startup_view.jsp</value>
</init-param>
<expiration-cache>300</expiration-cache> --Default expiration for portlet cache (5 minutes)
<supports>
<mime-type>text/html</mime-type> --Portlet supports HTML markup
<portlet-mode>VIEW</portlet-mode> --MyPortlet supports modes view and edit
<portlet-mode>EDIT</portlet-mode>
</supports>
<resource-bundle>com.abc.portlet.MyResourceBundle</resource-bundle>
<portlet-preferences>
<preference>
<name>Country1</name> --PortletPreferences name/value pairs.
<value>USA</value>
</preference>
<preference>
<name>Country2</name>
<value>Japan</value>
</preference>
--A PreferencesValidator will check any preferences set.
<preferences-validator>com.abc.portlet.validate.CountryValidator</preferences-validator>
</portlet-preferences>
</portlet>
</portlet-app>
Conclusion
The Java Portlet Specification has already been widely adopted by several commercial and open-source vendors. Going forward, portlet developers can take advantage of this standard, thereby insuring compatibility among many different portals. Updates made to this specification are sure to provide an even greater set of capabilities. For more information on the specification and its progress, visit its Java Community Process page.
My next Java article on the Java Portlet Specification will step through the coding and deployment of a working portlet application.
About the Author
Michael Klaene is a Senior Consultant with Sogeti LLC. He has spent over 7 years in IT, specializing in J2EE and Oracle analysis and development.
IE 7
Firefox 2.0
