Portlets
- Overview
- Portlet applications
- Portlet API
- Portlet communications
- Discoverable services
- Creating and customizing portlet applications
Overview
Portlets are small portal applications that are independently developed, deployed, managed, and displayed. Administrators and users compose personalized portal pages by choosing and arranging portlets, resulting in customized Web pages.
WebSphere Portal ships a set of standard portlets.
For the most up-to-date information about portlets, including the latest portlets that are available for download, visit the IBM Workplace Solutions Catalog
Portlet applications
Portlets are more than simple views of existing Web content. A portlet is a complete application, following a standard model-view-controller design. Portlets have multiple states and view modes, plus event and messaging capabilities.
Portlets run inside the portlet container of the WebSphere Portal component, similar to the way a servlet runs on an application server. The portlet container provides a run-time environment where portlets are instantiated, used, and finally destroyed. Portlets rely on the WebSphere Portal infrastructure to access user profile information, participate in window and action events, communicate with other portlets, access remote content, look up credentials, and store persistent data.
Generally, portlets are administered more dynamically than servlets. For example, portlet applications consisting of several portlets can be installed or removed while the WebSphere Portal component is running. The settings and access rights of a portlet can be changed by an administrator while WebSphere Portal is running, even in a production environment.
Portlet modes allow a portlet to display a different user interface, depending on the task that is required of the portlet. A portlet has several modes of display that can be invoked by icons on the portlet title bar: View, Help, and Edit.
A portlet is initially displayed in View mode. As the user interacts with the portlet, the portlet can display a sequence of view states, such as forms and responses, error messages, and other application-specific states. Help mode provides user assistance. Edit mode provides a page for users to change portlet settings. For example, a weather portlet might provide an Edit page for users to specify location. Users must be logged in to WebSphere Portal to access Edit mode.
Each portlet mode can be displayed in normal, maximized, or minimized states. When a portlet is maximized, it is displayed in the entire body of a page, replacing the view of other portlets. When a portlet is minimized, only the portlet title bar is displayed on the page.
Portlet API
Portlets are a special subclass of HttpServlet, with properties that allow them to plug in to and run in WebSphere Portal. Portlets are assembled into a larger page, with multiple instances of the same portlet displaying different data for each user. Portlets rely on WebSphere Portal infrastructure to access user profile information, participate in window and action events, communicate with other portlets, access remote content, look up credentials, and store persistent data. The Portlet API provides standard interfaces for these functions.
The portlet API defines a common base class and interfaces for portlets to cleanly separate the portlet from WebSphere Portal infrastructure. In most respects, the portlet API is an extension of the servlet API, except that it restricts certain functions to a subset that makes sense for portlets that are running in the context of a portal. For example, unlike servlets, portlets cannot send errors or redirects as a response. These responses are sent only by WebSphere Portal itself, which controls the overall response page.
Usually, many portlets are invoked in the course of handling a single request, each one appending its content to the overall page. Some portlets can be rendered in parallel, so that WebSphere Portal assembles all the markup fragments when all the portlets finish or time out. Portlets that are not considered to be thread-safe are rendered sequentially.
The markup fragments that portlets produce can contain links, actions, and other content. The Portlet API defines URL rewriting methods that allow portlets to transparently create links, without the portlet needing to know how URLs are structured in the particular portal.
Portlet communications
WebSphere Portal provides a way for portlets to communicate with each other. In a production portal, portlet communication could be used to copy common data between portlets. This method saves redundant typing for the user and makes WebSphere Portal easier to use. For example, one portlet might display information about accounts while a second portlet displays information about transactions that have occurred for one of the accounts over the last 30 days. To do this, the transactions portlet needs to obtain the corresponding account information when it displays the transaction details.
This is accomplished by communication between the two portlets, using portlet actions and portlet messages. In this example, the account portlet creates a portlet action and encodes it into the URL that is rendered for displaying transactions. When the link is clicked, the action listener is called, which then sends a portlet message to send the necessary data.
Using this event and message feature helps unify portlet applications that access disparate back-end applications. WebSphere Portal provides a feature called cooperative portlets that dynamically binds portlets on a page for data exchange.
Discoverable services
The portlet API provides an interface to enable dynamic discovery of available services. Each service is registered in a portal configuration file and is accessed from the PortletContext.getService() method, which looks up the factory for the service, creates the service, and returns it to the portlet. This makes services available to all portlets without having to package the service code with the portlet.
WebSphere Portal provides discoverable services for its credential vault, for managing persistent TCP/IP connections, and for managing the WebSphere Portal content repository. Portal developers can implement new services, such as search, location, notification, content access, or mail services.
We can also group portlets together in a portlet application. Portlet applications are distributed and deployed using Web archive files (WAR). Portlet-specific extensions to the standard Web application deployment descriptor exist.
Create and customizing portlet applications
WebSphere Studio Site Developer provides a development, test, and debugging environment for portlet applications. We can implement the Java classes for portlet classes and test and debug the Java code. WebSphere Studio Site Developer also provides tools for creating Java Server Pages, HTML pages, images, and other related portal resources. In WebSphere Studio Site Developer, the portlet can be packaged into a WAR file and deployed to the run-time server.
Parent topic:
Key features