4 Understanding Portlet Development

This chapter provides conceptual and reference information that you might find useful as you begin to develop portlets with WebLogic Portal. For a detailed description of the components that are involved in portlet design, refer to the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal. For instructions on how to create each type of portlet, refer to Section 5.4, "How to Build Each Type of Portlet."

This chapter contains the following sections:

• Section 4.1, "Portlet Components"

• Section 4.2, "Resources for Creating Portlets"

• Section 4.3, "Portlet Rendering"

• Section 4.4, "JSP Tags and Controls in Portlets"

• Section 4.5, "Backing Files"

• Section 4.6, "Support for Apache Portals Bridges"

4.1 Portlet Components

Portlets are modular panes within a web browser that surface applications, information, and business processes. Portlets can contain anything from static HTML content to JSF applications to complex web services and process-heavy applications. Within a portal application, a portlet is represented as an XML file with a .portlet file extension. As you build portlets using Oracle Enterprise Pack for Eclipse, the XML elements and attributes are automatically built.

Figure 4-1 shows the components that make up a portlet, which are located in the .portlet file. Objects shown in gray text are described in more detail within the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.

Figure 4-1 Portlet Components

Description of "Figure 4-1 Portlet Components"

This section includes the following topics:

• Section 4.1.1, "Portlet Properties"

• Section 4.1.2, "Portlet Title Bar, Mode, and State"

• Section 4.1.3, "Portlet Preferences"

• Section 4.3.1, "Render and Pre-Render Forking"

• Section 4.3.2, "Asynchronous Portlet Content Rendering"

• Section 4.3.3, "Portlets as Popups (Detached Portlets)"

For more information about Look & Feel components, refer to the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.

4.1.1 Portlet Properties

Portlet properties are named attributes of the portlet that uniquely identify it and define its characteristics. Some properties—such as title, definition label, and Content URI—are required; many other optional properties allow you to enable specific functions for that portlet such as scrolling, presentation properties, pre-processing (such as for authorization) and multi-threaded rendering. The specific properties that you use for a portlet vary depending on your expected use for that portlet.

For detailed information on portlet properties and how to set them, refer to Section 9.1, "Portlet Properties."

4.1.2 Portlet Title Bar, Mode, and State

When you create a portlet, you can choose whether or not it should have a title bar. Also, all portlets created with WebLogic Portal support modes and states. Modes affect the portlet's content; edit, help, and custom modes are available. States affect the rendering of the portlet; minimize, maximize, normal, float, and delete states are available.

You must enable the title bar on a portlet if you want to set modes and states for that portlet.

In certain situations your selection of a mode and state for a portlet might affect your ability to set up other portlet features, such as interportlet communication. For example, if you are setting up an event handler that listens to a portlet, you can select to execute the event handler only if the portlet to which it is listening is in a window that is not minimized.

For detailed instructions on setting portlet modes and states, refer to Section 9.5, "Portlet Appearance and Features."

4.1.3 Portlet Preferences

Portlets are distinct applications that you can reuse in a given portal. Once you create a portlet, you can instantiate it several times.

Along with the ability to create multiple instances of portlets, WebLogic Portal allows you to specify preferences for portlets. You use preferences to cause each portlet instance to behave differently yet use the same code and user interface. Portlet preferences provide the primary means of associating application data with portlets; this feature is key to personalizing portlets based on their usage.

Plan a portlet implementation that allows portlets to be as reusable as possible; planning for reuse simplifies your development and testing efforts because you can differentiate generic portlets by setting unique preferences.

For detailed instructions on setting portlet preferences, refer to Section 9.2, "Portlet Preferences."

4.2 Resources for Creating Portlets

Although the Portlet Wizard provides an easy way to create portlets, you might find that it is not your primary means of creating them. You can create a portlet in many ways, such as duplicating existing portlets or generating a portlet based on an existing JSP or JSF module. Many resources can provide the raw material for a portlet, including the following:

• Portlets in J2EE Shared Libraries – Portlets are provided with WebLogic Portal, which you can copy into your project and modify for your use. For example, you can add the Collaboration Portlets (pre-built portlets that are supplied with WebLogic Portal) to your Portal Web Project, and have access to Calendar, Task, Address Book, Discussion, and Mail portlets. For more information on the Collaboration portlets, including installation instructions, see Chapter 16, "Using the Collaboration Portlets."

• Third-party portlets – Special-purpose portlets provided as separate products by partner companies.

• Existing JSPs, Struts modules, and Page Flows – Existing resources that you can drag onto a portal page to automatically generate a portlet.

  Note:

  Page Flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. Apache Struts is also an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.

You can find detailed instructions on how to use these resources as the basis for a portlet in Chapter 5, "Creating Portlets."

4.3 Portlet Rendering

Portlet rendering consists of two life cycle stages:

• Pre-rendering – The background work to obtain necessary data or to perform pre-processing

• Rendering – The actual drawing of the portlet onto the portal page

General rendering topics are covered in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal. This section contains the following portlet-specific rendering topics:

• Section 4.3.1, "Render and Pre-Render Forking"

• Section 4.3.2, "Asynchronous Portlet Content Rendering"

4.3.1 Render and Pre-Render Forking

By default, pre-rendering and rendering for each portlet on a page is performed in sequence, and the portal page is not displayed until processing is complete for every portlet. This sequence can cause a noticeable delay in displaying the web page and might cause a user to think there is a problem with the web site. To prevent this situation, you can set up your portlets so that they perform pre-rendering and rendering tasks in parallel using multi-threaded forked processing.

Forking portlets at the rendering stage is supported for all portlet types. Pre-render forking is supported for the following portlet types:

• JSP

• Page Flow

• Java (JSR286)

• WSRP (consumer portlets only)

For detailed instructions on implementing forked portlets, refer to Section 10.4, "Portlet Forking."

Note:

Page Flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.

4.3.2 Asynchronous Portlet Content Rendering

Asynchronous portlet rendering allows the content of a portlet to be rendered independently of the surrounding portal page. When using asynchronous portlet rendering, a portlet is rendered in two HTTP requests. The first phase is the normal portal page request during which the portlet's non-content areas, such as the title bar, are rendered; a second request causes the portlet's content to render in place.

For detailed instructions on implementing asynchronous content rendering, refer to Section 10.5, "Asynchronous Portlet Content Rendering."

Tip:

You can also enable asynchronous rendering for an entire portal desktop by setting a portal property in either Oracle Enterprise Pack for Eclipse or the WebLogic Portal Administration Console. For more information on asynchronous desktop rendering, see the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.

4.3.3 Portlets as Popups (Detached Portlets)

WebLogic Portal supports the use of detached portlets. Detached portlets provide popup-style behavior.

For detailed instructions on using detached portlets, refer to Section 9.10, "Detached Portlets."

4.4 JSP Tags and Controls in Portlets

WebLogic Portal provides JSP tags that you can use within JSPs. Portlets can use JSPs as their content nodes, enabling reuse and facilitating personalization and other programmatic functionality. When you use the Palette view in Oracle Enterprise Pack for Eclipse, you can view available JSP tags and then drag them into the Source View of your JSP, and use the Properties view to edit elements of the code.

JSP tag libraries appear in the Design Palette whenever the JSP editor is open. If you do not see this palette, select Window > Show View > Design Palette. Select Tag Libraries from the palette's drop down menu to show only the tag libraries.

WebLogic Portal also provides custom Apache Beehive controls that make it easy for you to quickly add pre-built modules to your portal; custom Apache Beehive controls exist for event management, Visitor Tools, Community management, and so on. For example, most user management functionality can be easily exposed with a User Manager Control on a page flow.

Note:

The term control is also used to refer to the portal (netuix) framework controls, such as desktop, book, page, and so on. These controls are referred to in the text as portal framework controls.

For information about the classes associated with WebLogic Portal's JSP tags, refer to the Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal.

For more information about using Apache Beehive controls within portlets, see Section 9.7, "JSP Tags and Controls in Portlets."

Note:

Page Flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.

4.5 Backing Files

The most common means of influencing portlet behavior within the control life cycle is to use a portlet backing file. A portlet backing file is a Java class that can contain methods corresponding to Portal control life cycle stages, such as init() and preRender(). You can use a portlet's backing context, an abstraction of the portlet control itself, to query and alter the portlet's characteristics. For example, in the init() life cycle method, a request parameter might be evaluated, and depending on the parameter's value, the portlet backing context can be used to specify whether the portlet is visible or hidden.

Backing files can be attached to portals either by using Oracle Enterprise Pack for Eclipse or coding them directly into a .portlet file.

For detailed instructions on implementing backing files, refer to Section 9.4, "Backing Files."

4.6 Support for Apache Portals Bridges

WLP supports Apache Portals Bridges, a technology that provides support for JSR 168 compliant portlet development using common web frameworks like Struts, JSF, PHP, and others.

If using the Apache Portals Bridges, the WLP implementation of the ServletContextProvider interface is available as com.bea.portlet.container.ServletContextProviderImpl. For more information on Portals Bridges, see http://portals.apache.org/bridges.