LookupDispatchAction

In Chapter 3 you were introduced to a Localization problem with the Action class when the form has multiple buttons . Using LookupDispatchAction is one way of addressing the problem when regular buttons are used. Chapter 6 presents another alternative that works irrespective of whether an Image or a grey button is used to submit the Form. One has to choose the most appropriate solution under the given circumstances.

LookupDispatchAction is a subclass of DispatchAction as its name suggests. We will use a slightly modified example to illustrate the use of LookupDispatchAction . We will still use the list of credit applications as before, but with one twist. Each row in the list is a HTML Form and the images are now replaced with grey buttons to submit the Form. Figure 4.2 shows the modified application list as seen by the bank personnel.

Figure 4.2: Modified Screen Credit Applications page as seen by the bank staff.

A LookupDispatchAction for this example is created by following these steps.

1. Create a subclass of LookupDispatchAction.

2. Identify the related actions and create a method for each of the logical actions. Verify that the methods have the fixed method signature as similar to DispatchAction methods in Listing 4.1.

3. Identify the request parameter that will uniquely identify all actions.

4. Define an ActionMapping in struts-config.xml in the same way as DispatchAction (Listing 4.2). Assign the previously identified request parameter as the value of the parameter attribute in the ActionMapping. All the steps up until this point are the same as what you did before with DispatchAction . From here on, they will differ .

5. Implement a method named getKeyMethodMap() in the subclass of the LookupDispatchAction . The method returns a java.util.Map . The keys used in the Map should be also used as keys in Message Resource Bundle. The values of the keys in the Resource Bundle should be the method names from the step 2 above. If the CreditAppAction from the bank example were to be implemented as a LookupDispatchAction it would look like Listing 4.3.

   Listing 4.3: Example LookupDispatchAction

    public class CreditAppAction extends LookupDispatchAction {    public ActionForward reject(ActionMapping mapping,                                 ActionForm form,                                HttpServletRequest request,                                HttpServletResponse response)                                throws Exception    {        ... ... ...    }    //Other methods go here       public Map getKeyMethodMap()    {       Map map = new HashMap();       map.put("button.approve", "approve");       map.put("button.reject", "reject");       map.put("button.comment", "addComment");    } } 

    

6. Next, create the buttons in the JSP by using < bean:message > for their names. This is very important. If you hardcode the button names you will not get benefit of the LookupDispatchAction . For instance, the JSP snippet for Approve and Add Comment button are:

    <html:submit property="step"> <bean:message key="button.approve"/>            </html:submit>                      <html:submit property="step"> <bean:message key="button.comment"/>            </html:submit> 

   The < bean:message > keys point to the messages in the Resource Bundle.

    button.approve=Approve                  button.reject=Reject                  button.comment=Add Comment 

In summary, for every form submission, LookupDispatchAction does the reverse lookup on the resource bundle to get the key and then gets the method whose name is associated with the key into the Resource Bundle (from getKeyMethodmap() ). That was quite a bit of work just to execute the method. DispatchAction was much easier!

But the implications of LookupDispatchAction are significant. The method name in the Action is not driven by its name in the front end, but by the Locale independent key into the resource bundle. Since the key is always the same, the LookupDispatchAction shields your application from the side effects of I18N.