Understanding the basics

This section introduces you to the concepts of portlet creation, starting with a simple portlet that is modified throughout.

For more information about the classes and methods used in this section, read the concepts described in the portlet API. As you start to develop more complex portlets, make sure you are familiar with the guidelines for best practices.

If you are developing a portlet that will be provided as a WSRP service, refer to Using WSRP services and Hints and tips for using WSRP with the portal for information about the WSRP support in the portal.

Setting up the development environment
Creating a simple portlet
Generating output
Storing user settings
Preference layers and portlet modes
This topic gives an overview of portlet configuration preference layers and portlet modes. It describes how you best implement the different layers on which preferences for portlet views can be configured.
Message and trace logging
Portlets can write message and trace information to log files, which are maintained in the PortalServer_root/log/ directory. The log files help the portal administrator investigate portlet errors and special conditions and help the portlet developer test and debug portlets.
Caching portlet output
Portlet output can be cached at the local application server or using a remote proxy server.
Accessing remote systems
The portlet API provides a ContentAccessService, which allows portlets to access remote systems or content from remote URLs, including URLs located on the other side of a proxy server. You should always use this service to access remote content if you cannot be certain whether a firewall will be present after the portlet is deployed into a production environment.
Portlet authentication
For resources protected by the portal, IBM WebSphere Portal Express uses CORBA credentials and an encrypted LTPA cookie to authenticate users. However, for backend systems that require their own authentication, portlets need to provide some form of authentication to access these remote applications. In order to provide a single sign-on user experience, portlets must be able to store and retrieve user credentials for their particular associated application and use those credentials to log in on behalf of the user. WebSphere Portal Express supports the use of a credential vault where users and administrators can safely store credentials for authentication. Portlets written to extract the user's credentials from the vault can hide the login challenge from the user.
Accessing the portlet session on the anonymous page
Portlet menus
Writing a portlet filter
A portlet filter is an object that allows information flowing to or from a portlet (or filter) to be intercepted and manipulated. The object being filtered is intentionally left unaware of the filter's presence, allowing it to behave normally. Such an object can either be a portlet or another filter, thus allowing any number of filters to be applied to a single portlet, creating a filter chain (see the illustration below). While portlet filters can be used to manipulate data in any number of ways, one of their primary functions, for example, is to filter a portlet's input and results for use in secondary user interface environments (e.g., text terminals, PDAs, cell phones, and so on.). Because the portlet being filtered does not know about the filter, it can receive and respond to requests in a normal and robust fashion.
Client profile information (CC/PP) in portlets

Parent topic: Developing portlets