Form Handler Porting

Problem: Different concepts between ATG Form Handlers and Spring MVC

While Spring MVC entirely follows Model-View-Controller design pattern, ATG Form Handler architecture does not. Maybe we should rephrase that, “While Spring MVC makes your application follow MVC design pattern, ATG Form Handler does not”. Spring has a nice separation between Model, View and Controller. Spring has introduced nice abstractions for every part of MVC architecture, you have your controllers annotated with @Controller annotation, your model objects (often called command objects) annotated with @ModelAttribute and you decide which view will be rendered by returning View abstraction from your handle method. ATG does not have such a nice clean separation of concerns. In ATG, in most of applications,   Model and Controller are joined together.

Also ATG Form Handlers action/handle methods react somewhat similar to Struts actions. You decide which method will react to form submission with <dsp:input type=”submit”/> tag, by setting bean attribute to reference the component and method. In ATG targeted URL is not involved at all when making the decision which form handler will react. On the other side, in Spring every controller reaction is based on targeted URL by applying appropriate @RequestMapping annotations.

Solution:

Because our client wanted full MVC design pattern to be followed, we needed a way to extract Model and Controller from Form Handlers. We have created two base classes for this BaseController and BaseCommand. This was needed because for the future refactoring and extending of features and also for AOP aspects we may need to create. Extraction consisted of:

  1. Making our new controller extend BaseController
  2. Moving all properties      (except properties which referenced other ATG components) from Form      Handler to appropriate model class.
  3. Delegating all calls      for these properties to go through appropriate command object
  4. Depending on the scope      of Form Handler component make command object request or session scope
  5. Make appropriate model      factory method and annotate it with @ModelAttribute

Next step was to port handler methods. This required more complex instructions and more involvement from developer. First we needed to locate all places where this handle method is referenced. Then annotate method with @RequestMapping and add all action URLS to this mapping. Then change method signature to accept another argument, command object class, so binding of parameters will occur.

An example of ATG handler method from FooFormHandler is given below:

public boolean handleFoo(
    DynamoHttpServletRequest pRequest,
    DynamoHttpServletResponse pResponse)

References of this form handler in JHTML or DSP pages are given below:

<dsp:form action="/context/path1">
    ...
    <dsp:input type="submit" bean="FooFormHandler.foo"/>
    ...
</dsp:form>
<dsp:form action="/context/path2">
    ...
<dsp:input type="submit" bean="FooFormHandler.foo"/>
    ...
</dsp:form>

After refactoring the final code was looking as given below:

@RequestMapping(value = {"/path1" "/path2"}, method = RequestMethod.POST)
public String handleFoo(
    @ModelAttribute("fooCommand") FooCommand command,
    HttpServletRequest request, HttpServletResponse response)
Tech Team

Author: Tech Team

When a couple of our Devs and TLs come together magic happens!

Leave a Reply

Your email address will not be published. Required fields are marked *