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 Development 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 IBM® portlet API and the JSR 168 (also known as the standard)
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 high-level list of activities are involved in developing
Struts portlet applications:
- Creating a Struts portlet project.
- Designing the Struts portlet application, typically using the Web diagram
editor (WDE).
- Creating and modifying artifacts that are associated with a Struts portlet
application.
You will use various wizards to generate these artifacts, including
Struts portlet-specific JSP and Java files. If you use the Web Diagram editor,
you can use the standard menu options and drag-and-drop from available palette
drawers to create node representations (without underlying code) of the artifacts
that you need. When you realize a node by double-clicking it, the appropriate
wizard is invoked to generate the artifact associated with the node.
- Navigating to related artifacts and viewing the project in a logical manner,
using the Struts Explorer and Project Explorer.
- Running and testing the Struts portlet application.
- Setting up related preferences, if necessary.
- Validating that the project is correct.
Rational Software
Development Platform 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
Development 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 that do not map well to execution in the Rational Software Development Platform
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.