Page 3 of 4
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 the Action 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 method processActionPerform(). In the overridden method, after the call to super.processActionPerform(), ActionForward's path should be stored in the Stack.
In the application's parent Action class, provide methods to traverse forward and backward in the Stack.
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 ActionForwards 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.
