Struts portlet applications

Struts-based application development can be applied to portlets, similar to the way that Struts development is implemented in Web applications. Because of the differences in the Struts and Portal technologies, the Struts Portal Framework (SPF) was developed to merge these two technologies. The SPF support in Rational® Developer simplifies the process of writing Struts portlet applications and eliminates the need to manage many of the underlying requirements of portlet applications.

The Struts portlet tooling supports development of portlet applications based on both the IBM® portlet API and the JSR 168 (also known as the standard) API. There are differences in the run-time code included with projects, tag libraries supported, Java™ class references, and configuration architecture, but, unless otherwise noted, these differences are managed by the product tooling.

The following high-level list of activities are involved in developing Struts portlet applications:
Rational Developer provides a set of wizards that help you create Struts portlet-related artifacts. These wizards are the same wizards used to create standard Struts artifacts. Based on the development context, portlet-specific model options are provided as defaults. However, in some cases you may need to select a Model value that specifies portlet-specific file and code-generation behaviors. Please refer to the Rational Developer (standard) Struts documentation and F1 help for additional usage details. To summarize how the wizard behaviors vary (if at all) between portlet and non-portlet models, see the following list:
Action Class wizard
Provides support for the enhanced SPF action class, StrutsAction, which hides details that do not map well to execution in the Rational Developer environment.
Action Mapping wizard
Supports the SPF changes added to the Action Class wizard.
ActionForm wizard
No difference.
Form-Bean Mapping wizard
No difference.
Struts Configuration File wizard
Adds the required <controller> section that specifies the com.ibm.wps.portlets.struts.WpsRequestProcessor processor class when creating the configuration file (for an IBM API portlet). For a JSR 168 API portlet, the com.ibm.portal.struts.portlet.WpRequestProcessor processor class is used.
Struts Module wizard
Minor differences:
  • For an IBM API portlet, he <init-param> entry that specifies a module is added under the WpsStrutsPortlet servlet entry instead of the ActionServlet servlet entry. For a JSR 168 API portlet, the module is specified in the portlet.xml file as part of the Struts portlet definition.
  • The Struts configuration files specified by modules include the required <controller> section.
Struts Exception wizard
No difference.
Web Diagram wizard
No difference.
Related concepts
Struts Portlet Framework
Creating Struts portlets and projects
Struts-based Web applications - overview
Struts tools for application development
Web diagrams and the Web diagram editor
Related tasks
Creating Struts portlet projects
Creating Struts portlets
Creating well-architected Web applications using Struts
Creating Web diagrams for new applications
Related reference
Differences between Struts 1.1 and SPF tag library classes

(C) Copyright IBM Corporation 2002, 2005. All Rights Reserved.