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:
- 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 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.