Prepopulation
Problem
One requirement difficult to achieve is data prepopulation in a drop-down list (HTML Select tag) or in other fields. Some of these values come from a database, some from the application's context, and the rest are passed from calling screens. These values must be populated in a form bean before forwarding the control to the JSP page.
Struts best practice
The form bean's prepopulation can be accomplished using one of the following approaches:
- The on-demand lazy-loading technique for all such data in the application's context, which is required for prepopulation. An application screen's (JSP page) invocation mechanism can always be routed though a specific method of corresponding
Action
classes. Prepopulation-related code can be placed in this method. - Have different
Action
classes—one for requesting and another for submitting the JSP pages. The entire module or application can share theAction
class used for requesting.
The second approach works well for small applications. However, for large applications, managing numerous Action
classes grows cumbersome. Therefore, the first approach should be adopted.
Stack maintenance (for bread crumbs)
Problem
What if you need to go to a JSP page from two or more different JSP pages and subsequently return to the calling JSP page? Similarly, often developers need to go to various JSP pages in a criss-cross manner, which grows more complex when breadcrumbs need to be shown. Thus, the application must remember the pages visited.
Struts best practice
The remedy is to maintain the paths of all the forwarded JSP pages in a Stack
(java.util.Stack
). The following steps are required for maintaining such a Stack
:
- Extend the
RequestProcessor
class and override the methodprocessActionPerform()
. In the overridden method, after the call tosuper.processActionPerform()
,ActionForward
's path should be stored in theStack
. - In the application's parent
Action
class, provide methods to traverse forward and backward in theStack
.
Another option is to utilize an already available open source project at sourceforge.net like Open Tranquera (see Resources for more details).
Context-related issues
Problem
If ActionForward
's path and the path to which the control is forwarded differ, a context problem has resulted. More such context-related problems are quite frequent in Struts-based applications, most of which can be solved using some of Struts' less exploited features.
Struts best practice
Mention the JSP page's name as a path for ActionForward
and let the prefix—i.e., the JSP page's access path—come from a preconfigured place. Do that in the following manner:
struts-config.xml(s)
has a controller
tag; add a property in this tag named forwardPattern
. This property's value can be prefixed to all the ActionForward
paths. This property's default value is $M$P
, which means the module prefix will be prefixed to ActionForward
's path. We can change this value to anything; e.g., WEB-INF/pages/$M$P
. As a result, all the ActionForward
paths will be searched in the directory WEB-INF/pages/
/
.
For above solution to work, make sure that ActionForward
's contextRelative
property is marked false. If this property is marked true, the ActionForward
paths will be taken since they are not modified.
Also note that for forwardPattern
to work, the path of all ActionForward
s must start with a /
.
Form-bean scope
Problem
A well-managed session context can greatly boost application performance. It is therefore important to understand the implications of marking the form-bean scope to request
, session
, or application
. However, the following confusions usually arise:
- If the scope of the form beans is marked
request
, how will the information available in one JSP page/screen also be available to another one? - If the scope is
session
, how will the server know that the client is no longer interested in that form bean and consequently destroy it?
Struts best practice
State can be maintained in HttpSession
(Web tier), in stateful session beans (EJB tier), or in a database. The appropriate choice should be based on what kind availability needs persist or whether the application is supposed to provide multichannel access. However, the rule of thumb is to maintain the state close to the tier that requires it most. Therefore, the best practice is to keep the state in HttpSession
; i.e., mark the form-bean scope to session
.
The important question is when and how to destroy the form beans stored in the HttpSession
. The session beans should be destroyed in an extended RequestProcessor
based on the least-recently-accessed, to-be-removed logic. Another approach is to destroy all the form beans as soon as the user invokes a new business operation, possibly from the application menu.