Understand the basics

Get introduced 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 we are familiar with the guidelines for best practices.

If we are developing a portlet that will be provided as a WSRP service, refer to Use WSRP services and Tips for using WSRP with the portal for information about the WSRP support in the portal.

• Sample portlets
  Learn about the sample portlets included with WebSphere Portal and view the steps to import these samples into IBM Rational Application Developer.
• Set up the dev environment
  Know the capabilities of two dev environments for developing portlet applications for WebSphere Portal, IBM Rational Application Developer and Web Experience Factory.
• Create a simple portlet
  View the basic steps for creating a simple portlets that include writing the portlet code, compiling java source, creating the JAR file, writing the portlet descriptors, setting up the WAR file directory structure, and packaging and deploying portlets.
• Generating output
  View how portlets use JSPs to generate markup, create URLs to portlet resources, support multiple devices, markups, and languages in IBM portlets, and make use of JSTL.
• Storing user settings
  Using a sample portlet as an example, learn how user settings can be stored and retrieved in portlets.
• Preference layers and portlet modes
  Get an overview of portlet configuration preference layers and portlet modes to 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 WP_PROFILE/logs/WebSphere_Portal 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.
• Access 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 we 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 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. 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 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.
• Client profile information (CC/PP) in portlets
  The Portal provides a standard API named "CC/PP" for accessing client profiles; learn how the client profile can be accessed through a request attribute. Learn about the attributes and components that are supported by the default profile implementation in the portal.

Parent: Develop portlets
Related:
Struts Portlet Framework