Moving from Servlets to Portlets

by Jeff Robinson

Making the switch to portlet development is easier than you think. That’s  largely because the writers of the initial specification (JSR-168) used the Servlet specification as the basis for their documentation.  The benefit of doing so means that portlets work very similarly to servlets except with additional modifications to account for the change in technology.

Here’s a few things you should know when preparing to make the switch to portlet development:

1. Both servlets and portlets use the web.xml deployment descriptor.  However, portlets also have an additional deployment descriptor, portlet.xml, which must declare all of the portlets that will be used by the portlet container.
2. Instead of HttpServletRequest and HttpServletResponse objects, portlets expect either an ActionRequest or RenderRequest object and ActionResponse or RenderResponse objects. There are limitations in the objects that portlets manage such as  not having direct access to original servlet request parameters (JSR 168). But check your portlet specification and portlet container implementation to verify which features may or may not be available.
3. Portlets have a Context interface which allows developers to access the portlet application under which a portlet is running. This is similar to the servlet’s context interface.
4. Portlets have their own config object, PortletConfig, which can be used to access properties within the portlet.xml.
5. Portlets use the concept of portlet modes which allows developers to provide varying levels of end-user control for viewing, editing, or accessing help.
6. Portlets have windows states of normal, maximized or minimized which determines how much a portlet can be seen within the portal window.
7. Listeners and Wrappers used by portlets are still declared within the web.xml deployment descriptor.
8. Sun provides a Portlet Tag library that is used for accessing portlet features from markup such as Java Server Pages or Velocity templates.
9. Portlets can expect to be invoked multiple times by the portlet container to update its area of the display. This means that rendering methods must contain idempotent code. When performing actions on a portlet, portlets should expect that the action will be performed only once and therefore should be non-idempotent.

Check the portlet specification that you’re using to see the complete list of features supported. Also, review your portal documentation to see how closely the portlet container follows the specification.

FrameWorks

Additionally, if you’re accustomed to using development frameworks such as Struts or Spring, you’ll find these to have customized class and tag libraries to allow you to continue to use their features within portlets. Usually, the libraries will have portlet class names and methods that correspond exactly to their servlet implementation.

For instance, Spring provides a servlet front controller named DispatcherServlet and a portlet front controller similarly named DispatcherPortlet.

Configuration

Also, additional configuration files are usually required by Liferay® when using portlets in additional to those used by frameworks. For instance, Liferay® expects developers to define a liferay-portlet.xml file which declares the name of portlets to be used by Liferay®. Another example is the Spring framework which expects the declaration of portlet specific configuration file which declares additional beans and properties to be used by the Spring controller when initializing the portlet.


Contributed By Liferay.com