Roll your own Base Action and Form


You have looked at different types of Actions offered by Struts. Now, let us look at some recommended practices in using Action. When it comes to using Actions, the brute force approach is to extend the actions directly from the org.apache.struts.action.Action . But a careful look at your web application will certainly reveal behavior that needs to be centralized. Sooner or later you will discover functionality common to all the actions. While it is impossible to predict the exact purposes of why you might need the base Action, here are some samples:

  • You might like to perform logging in Action classes for debugging purposes or otherwise to track the user behavior or for security audit purposes.

  • You might want to retrieve the user ‚ s profile from application specific database to check if the user has access to your application and act appropriately.

Whatever the purpose, there is always something done always in web applications warranting a parent Action class. Start with a common parent Action class. Let us call it MybankBaseAction . Depending on the complexities of the web application, you can further create child classes for specific purposes. For instance, an Action subclass for dealing with form submissions and another for dealing with hyperlink-based navigation is a logical choice if the Action classes handling hyperlink don ‚ t need an ActionForm. You might want to filter out some words typed in the form fields.

In conjunction with the base Action, you can also roll a base Form extending the org.apache.struts.action.ActionForm . Let us call this class MybankBaseForm . The base form fits well into the base action strategy. In chapter 2, we introduced the term View Data Transfer Object to refer an ActionForm. This isn ‚ t without a reason. Data Transfer Object is a Core J2EE pattern name . It is typically used between tiers to exchange data. The ActionForm serves similar purpose in a Struts application and you use to its very best. Typical uses of a base form would be:

  • Add attributes to the base form that are needed frequently in the web application. Consider a case when every Action in your web application needs to reference an attribute in the request or session. Instead of adding the code to access this attribute as request.getAttribute( ‚“attribName ‚½) everywhere, you can set this as an ActionForm attribute and access it in a type-safe manner in the application.

  • Retrieving the user ‚ s profile from application specific database and then set it as a form attribute on every call to MybankBaseAction ‚ s execute() method.

Listing 4.5 shows the MybankBaseAction using the MybankBaseForm . It implemented the execute() method and adds audit logging for entry and exit points. Further down the line, it retrieves the application specific profile for the user. This is helpful if you have a portal with a single sign-on and the user rights and profiles differ from one application to another. Then it casts the ActionForm to MybankBaseForm and assigns its variables with the values of commonly accessed request and session attributes. MybankBaseAction defines three abstract methods ‚ preprocess() , process() and postprocess() . These methods when implemented by the subclasses respectively perform pre-processing, processing and post-processing activities. Their signatures as as follows :

 protected  abstract  void preprocess(ActionMapping mapping,              MybankBaseForm form, HttpServletRequest request,                 HttpServletResponse response) throws Exception; protected  abstract  ActionForward process(ActionMapping mapping,              MybankBaseForm form, HttpServletRequest request,                 HttpServletResponse response) throws Exception; protected  abstract  void postprocess(ActionMapping mapping,              MybankBaseForm form, HttpServletRequest request,                 HttpServletResponse response) throws Exception; 
Listing 4.5: The Base Action class
 public class MybankBaseAction extends Action {    public ActionForward execute(ActionMapping mapping,               ActionForm form, HttpServletRequest request,               HttpServletResponse response) throws Exception    {       // Add centralized logging here (Entry point audit)         // Check here if the user has rights to this application       // or retrieve app specific profile for the user       MybankBaseForm myForm = (MybankBaseForm) form;       // Set common MybankBaseForm variables using request &       // session attributes for type-safe access in subclasses.       // For e.g. myForm.setUserProfile(       //                 request.getAttribute("profile"));       preprocess(mapping, myForm, request, response);       ActionForward forward =           process(mapping, myForm, request, response);       postprocess(mapping, myForm, request, response);       // More code to be added later.       // Add centralized logging here (Exit point audit)         return forward;    }  } 
 

Pre-processing activities involve validating the form (Validations requiring access to backend resources to are typically performed in the Action instead of ActionForm, where the validations are limited to trivial checking and inter-depdendent fields), checking for duplicate form submissions (In the next section you will look at the facilities in Struts to handle duplicate form submissions. In Chapter 10 we will develop the generalized strategy for duplicate form handling ‚ not just repeating synchronizer token in the Action classes.), checking if the action (page) was invoked in the right order (if a strict wizard like behavior is desired) etc.

Processing activities are the meat of the application and do not need any more explanation. Validation errors can be discovered in this stage too.

Post-processing activities may involve setting the sync token (for checking duplicate form submission), cleaning up unnecessary objects from request and session scopes and so on. The bottom line is that all applications have recurring tasks that need to be refactored into the parent class and hence a base Form and Action are a must for every serious application. In Chapter we will add a lot of functionality into the base Action giving you that many reasons to create the base Action.




Struts Survival Guide. Basics to Best Practices
Struts Survival Guide: Basics to Best Practices (J2ee Survival Series)
ISBN: 0974848808
EAN: 2147483647
Year: 2004
Pages: 96

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net