Struts portlet applications

 

+

Search Tips   |   Advanced Search

 

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 the Rational Software Delivery Platform 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 JSR 168 API and the IBM portlet API. There are differences in the runtime 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 is a list of high-level activities involved in developing Struts portlet applications:

Rational tools 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 Software Delivery Platform (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 of the Struts action class that do not map well to execution Portal runtime.

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 processor class...

com.ibm.wps.portlets.struts.WpsRequestProcessor

...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, the <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

Generating Struts portlet actions and action mapping codes

Creating data access Web applications using Struts

Struts tools for application development

 

Related tasks

Creating Struts portlet projects

Creating portlets

Creating Struts portlet JSP files

Creating Struts applications

 

Related reference

Differences between Struts 1.1 and SPF tag library classes