Portal, V6.1
Elements of the Portlet API
This section describes the basic interfaces, classes, and methods of the Portlet API. The following figure shows a map of many of the common objects in the Portlet API.
- Portlet
extended by
- service()1
- createURI()
- service()1
- getPortletSettings()
- getPortletApplicationSettings
- getMode()
- getClient()
- getData()
- getWindow()
- getWindowState()
- getPortletSession()
- getUser()
- getPortletConfig()
- getContext()
- getLog()
- getService()
1 PortletRequest and PortletResponse are passed by helper methods of PortletAdapter, such as doView().
Portlet class
The abstract Portlet class is the central abstraction of the Portlet API. All portlets extend this abstract class by extending one of its subclasses, such as PortletAdapter, that provide methods helpful for the developer.
- Portlet life cycle
- Portlet container calls the following methods of the abstract portlet during the portlet's life cycle :
- init()
- Portlet is constructed, after portal initialization, and then initialized with the init() method. The portal always instantiates only a single instance of the portlet, and this instance is shared among all users, exactly the same way a servlet is shared among all users of an application server.
- initConcrete()
- After constructing the portlet and before the portlet is accessed for the first time, the concrete portlet is initialized with the PortletSettings.
- service()
- Portal calls the service() method when the portlet is required to render it's content. During the life cycle of the portlet, the service() method is typically called many times. For each portlet on the page, the service() method is not called in a guaranteed order and may even be called in a different order for each request.
- destroyConcrete()
- The concrete portlet is taken out of service with the destroyConcrete() method. This can happen when an administrator deletes a concrete portlet during runtime on the portal server.
- destroy()
- When the portal is terminating, portlets are taken out of service, then destroyed with the destroy() method. Finally the portlet is garbage collected and finalized.
2 This represents the methods called on all portlets. Other methods are called for portlets that implement listeners. See the Listener lifecycle for more information.
- getLastModified()
- In addition to methods that are called during the portlet life cycle, the portlet container calls the getLastModified() method for each request. This method returns the last time the content of the portlet changed, in milliseconds, between the current time and midnight, January 1, 1970 UTC (java.lang.System.currentTimeMillis()) or a negative value if it is unknown. For more information about when to use getLastModified(), see Refreshing the portlet cache .
Helper classes
Portlets do not extend the abstract Portlet class directly, but rather extend PortletAdapter or any other helper class that in turn extends Portlet. Extending one of these classes helps protect your portlet from changes in the abstract Portlet class. Moreover it saves you the work of having to implement all of the methods of the Portlet interface, even if your portlet does not need to use them all. Using the PortletAdapter class, you only have to overwrite the methods you really need.
In its service() method, the PortletAdapter class invokes methods corresponding to the portlet mode. Portlets that extend this class can overwrite the doView(), doEdit(), and doHelp() methods without having to test the mode or write a specific service() method.
Additionally, the PortletAdapter enables a portlet to store variables with the concrete portlet. Concrete portlet variables differ from Java instance variables because they are bound to the portlet class or non-concrete portlet. PortletAdapter provides the methods setVariable(), getVariable() and removeVariable() to work with
concrete portlet variables.
Related information
Parent topic
IBM Portlet API