3 Portlet Types

As part of your portlet implementation plan, Oracle recommends that you examine the different types of portlets that are available in WebLogic Portal and decide which types are best suited for the tasks that you want to accomplish.

Tip:

Java Server Faces (JSF) technology provides the best interoperative facilities with the rest of the Oracle Fusion Middleware and WebCenter products.

If you are looking for a way to interface with Java controls, use Struts-based infrastructure, and deliver rich navigation elements, then you might choose to implement Java Page Flow or Struts portlets. If you are looking for a simple portlet or you want to convert an existing JSP page into a portlet, you might consider using a JSP portlet. If you work for an independent software company or other enterprise that is concerned with portability across multiple portal vendors, then you might choose to use JSR 286-compliant Java portlets whenever possible. If you want to implement asynchronous portlet rendering in your portal, you can use nearly any of the portlet types described in this chapter.

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.

This chapter differentiates the various portlet types to help you in your decision-making process. This chapter contains the following sections:

Section 3.1, "Java Server Faces (JSF) Portlets"
Section 3.2, "Java Server Page (JSP) and HTML Portlets"
Section 3.3, "Java Portlets"
Section 3.4, "Java Page Flow Portlets"
Section 3.5, "Struts Portlets"
Section 3.6, "Browser (URL) Portlets"
Section 3.7, "Clipper Portlets"
Section 3.8, "Remote (Proxy) Portlets"
Section 3.9, "Portlet Type Summary Table"

3.1 Java Server Faces (JSF) Portlets

The Java Server Faces (JSF) specification, JSR 127, defines a user interface framework that simplifies development and maintenance of Java applications that run on a server and are displayed and used from a client.

Note:

Oracle recommends JSF as the best approach to implementing portal applications. As one of the active members of the JSF expert group, Oracle has committed itself to evolve and support JSF.

According to the Java Server Faces Specification, available from the Java Community Process web site at http://jcp.org/aboutJava/communityprocess/final/jsr127/index2.html.

JSF's core architecture is designed to be independent of specific protocols and markup. However it is also aimed directly at solving many of the common problems encountered when writing applications for HTML clients that communicate via HTTP to a Java application server that supports servlets and JavaServer Pages (JSP) based applications. These applications are typically form-based, and are comprised of one or more HTML pages with which the user interacts to complete a task or set of tasks. JSF tackles the following challenges associated with these applications:

Managing UI component state across requests
Supporting encapsulation of the differences in markup across different browsers and clients
Supporting form processing (single multi-page form, or more than one form per page)
Providing a strongly typed event model that allows the application to write server-side handlers (independent of HTTP) for client generated events
Validating request data and providing appropriate error reporting
Enabling type conversion when migrating markup values (Strings) to and from application data objects (which are often not Strings)
Handling error and exceptions, and reporting errors in human-readable form back to the application user
Handling page-to-page navigation in response to UI events and model interactions.

For instructions on building Java Server Faces portlets, refer to Section 5.4.2, "Building JSF Portlets."

3.2 Java Server Page (JSP) and HTML Portlets

JSP portlets and HTML portlets point to JSP or HTML files for their content. These portlets can be simple to implement and deploy, and they provide basic functionality quickly. However, this type of portlet does not enforce separation of business logic and the presentation layer. As the application grows, the portlet often becomes harder to maintain as you try to update the web application and share code. JSP portlets are not well-suited for advanced portlet navigation.

When using JSP pages as part of a page flow portlet, you must make sure that requests adhere to WebLogic Portal scoping requirements. For more information about JSP portlets and page flow scoping, refer to the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.

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.

For instructions on building JSP portlets, see Section 5.4.1, "Building JSP and HTML Portlets."

3.3 Java Portlets

JSR 268 (Java Portlet) is a Java specification that aims at establishing portability between portlets and portals. One of the main goals of the specification is to define a set of standard Java APIs for portal and portlet vendors. These APIs cover areas such as presentation, aggregation, security, and portlet life cycle.

A Java portlet is expressed as a Java class. This type of portlet accommodates portability across platforms, and does not require the use of portal server-specific JSP tags. The behavior is similar to a servlet. Java portlets produced using WebLogic Portal can be used universally by any other vendor's application server container that supports JSR 268.

For instructions on building Java portlets, refer to Chapter 6, "Building Java Portlets."

3.4 Java Page Flow Portlets

Note:

Oracle recommends you choose an alternative supported Portlet type, such as JSF, over Java Page Flow / Apache Beehive technology. WLP will continue to support Page Flows and Apache Beehive, however the technology will be deprecated over time and will not see significant new enhancements.

A Java page flow portlet uses Apache Beehive page flows to retrieve its content. This portlet type allows you to separate the user interface code from navigation control and other business logic, and provides the ability to implement both simple and advanced portlet navigation.

The Page Flow framework is built on top of the Struts application framework. The Struts framework is a popular, reliable standard that is widely used to quickly create robust and navigable web applications. The page flow framework adds valuable data binding facilities to the Struts standard, and the portal framework provides a scoping capability for page flow portlets so that multiple page flows can be supported in a single portal. You can use resources such as Java controls and web services.

For instructions on building Java page flow portlets, refer to Section 5.4.8, "Building Java Page Flow Portlets."

3.5 Struts Portlets

Note:

Apache Struts 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.

Struts portlets are based on the Struts framework, which is an implementation of the Model-View-Controller (MVC) architecture. The MVC architecture provides a model for separating the different components and roles of the application logic. This development framework helps you create portlets that are easier to maintain over time.

Typically, native Struts development requires management and synchronization of multiple files for each action, form bean, as well as the Struts configuration file. Even in the presence of tools that help edit these files, developers are still exposed to all the underlying plumbing, objects, and configuration details.

For instructions on building Struts portlets, refer to Section 5.4.6, "Building Struts Portlets."

3.6 Browser (URL) Portlets

Browser portlets display HTML content from an external URL. Unlike other portlet types that are limited to displaying data contained within the portal project, browser portlets display URL content that is external from the portal project.

An advantage of browser portlets is that no development tasks are required to implement it, either from the Oracle Enterprise Pack for Eclipse workbench or from the WebLogic Portal Administration Console. However, keep in mind that WebLogic Portal does not provide a mechanism to develop content for this type of portlet; the definition of the portlet merely contains the external URL to display. For example, no mechanisms exist to dynamically influence the external content's URL; no support exists for portlet preferences, portlet modes, and so on. Browser portlets do not track the URL through the user's interaction with remote content – page refreshes cause the content of the URL specified in the portlet definition to be displayed.

WebLogic Portal implements a browser portlet using an IFRAME. You can override the default implementation mechanism using more advanced development techniques.

The content of the browser portlet is completely disconnected from the portal. The embedded application must manage the navigational state of the portlet.

For instructions on building Browser portlets, refer to Section 5.4.4, "Building Browser Portlets."

3.7 Clipper Portlets

Clipping is an easy technique for including content in your portal. You can clip all or part of another web site. Users can effectively view and interact with content from another web site without leaving the portal. For detailed information on creating clipper portlets, see Chapter 7, "Creating Clipper Portlets."

3.8 Remote (Proxy) Portlets

WebLogic Portal supports the Web Services for Remote Portlets (WSRP) standard, a product of the OASIS standards body. Portlets that are written to meet this standard, which includes a WSDL portlet description, can be hosted within a producer application, and surfaced in a consumer application. Moreover, the WebLogic Portal Administration Console facilitates access to WSRP producer applications in a local portal.

WebLogic Portal can act as either a WSRP remote producer or as a consumer. When acting as a consumer, WebLogic Portal's remote—or proxy—portlets are WSRP-compliant. These portlets present content that is collected from WSRP-compliant producers, allowing you to use external sources for portlet content, rather than having to create its content or its structure yourself.

Because setting up a remote portlet is a fundamental task in creating a federated portlet environment, the task of creating a remote portlet is described in detail within the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal.

3.9 Portlet Type Summary Table

Table 3-1 summarizes the characteristics of each portlet type so that you can quickly determine the advantages and disadvantages of each type.

Table 3-1 Portlet Type Summary Table

Type	Advantages	Disadvantages
JSF	Allows component-based development of pages that can handle their own intra-page events. Simplifies separation of the user interface code from navigation control and other business logic. Provides the ability to implement both simple and advanced portlet navigation. Allow you to quickly leverage Java controls, web services, and business processes. Note: Oracle recommends JSF as the best approach to implementing portal applications. As one of the active members of the JSF expert group, Oracle has committed itself to evolve and support JSF.	All postbacks to a JSF application are expected to be done using a POST; the GET method is not supported.
JSP/HTML	Simple to implement and deploy. Provides basic functionality without complexity.	Does not enforce separation of business logic and presentation layer. Not well-suited for advanced portlet navigation.
Java (JSR 286)	Accommodates portability across platforms. Does not require the use of portal server-specific JSP tags. Behavior is similar to a servlet	Lack of advanced portlet features that are available with some other portlet types. Requires a deeper understanding of the J2EE programming model.
Java Page Flow	Allows separation of the user interface code from navigation control and other business logic. Provides the ability to implement both simple and advanced portlet navigation. Allow you to quickly leverage Apache Beehive controls, web services, and business processes. Provides a visual environment to build rich applications based on struts. 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.	Implementation is more complex. Advanced page flow features are not necessary for static or simple, one view portlets.
Browser	Allows a portlet to display content from a URL that is outside the portal project. Provides a "no development needed" portlet for quick implementation.	Less control over formatting. Lacks certain features of other portlet types, such as Content Path and Error Path. No interportlet communication support.
Clipper	Lets you subset or modify the contents of a remote web page. The portal can potentially access the clipper portlet's content.	Clipped content is included directly in the portal page, allowing the potential for overlapping with other parts of the portal.
Struts	Provides a flexible control layer based on standard technologies like Java Servlets, JavaBeans, ResourceBundles, and XML. Provides a more structured approach for creating and maintaining complex applications. Useful for importing existing applications. Note: 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.	Not quite as robust as page flow portlets, which are based on Apache Beehive. For new development, page flow portlets provide a better solution.
Remote	Allows you to functionally and operationally de-couple applications within your portal. Allows you to leverage external sources for portlet content. Depending on the environment, might improve performance.	Implementation is more complex. Your application's features might not be able to be as robust; for example, some Javascript might not perform correctly. Depending on the environment, might have a performance cost. For more about performance with remote portlets, refer to Section 10.3, "Remote Portlets."