Portlet Types

As part of your portlet implementation plan, BEA 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. For example, 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 168-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.

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

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 Portal Development Guide.

Java Portlets (JSR 168)

JSR 168 (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 168.

Java Page Flow Portlets

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 that is recommended for portlet application development 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.

Java page flow portlets are best suited for an environment where more advanced features are required—not for static, single-view portlets.

Struts Portlets

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. The Page Flow implementation provides a simpler, single-file programming model that allows developers to focus on the code they care about, see a visual representation of the overall application flow, and navigate between pages, actions, and form beans.

If you are developing a portal application from scratch, BEA recommends using a Page Flow implementation; if your goal is to aggregate an existing Struts application, then using Struts portlets can meet your needs.

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.

According to the Java Server Faces Specification, available from the Java Community Process web site:

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.

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 Workshop for WebLogic 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; more detailed documentation about these techniques will be provided in a future dev2dev article.

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

Remote 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 Federated Portals Guide.

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
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 168)	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 Java controls, web services, and business processes. Provides a visual environment to build rich applications based on struts.	Implementation is more complex. Advanced page flow features are not necessary for static or simple, one view portlets.
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.	All postbacks to a JSF application are expected to be done using a POST; the GET method is not supported.
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.
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.	Not quite as robust as page flow portlets, which are based on 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 Remote Portlets.

Portlet Development Guide