Announcement Announcement Module
Collapse
No announcement yet.
SetCommandClass versus hard coded formBacking object Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • SetCommandClass versus hard coded formBacking object

    The command object is usually a one-to-one relationship with the Form Controller and Validator.

    On one hand, the command class can be hard coded in the Controller/Validator such as:
    Code:
    public MyController extends SimpleFormController {
      public Object formBackingObject() {
        MyForm command = new MyForm();
        command.setYada(yada);
        ...
        return command;
      }
    }
    On the other hand, the command class can be injected such as:
    Code:
    <bean id="MyController" class="com...MyController">
      <property name="commandClass" value="com...MyForm"/>
      <property name="commandName" value="myform"/>
    </bean>
    Can someone list off some advantages to wiring the commandClass instead of just leaving it hard coded?
    As well, are there useful situations where you want to rename the commandName from "command" to "myform"?


    Jeff Lee

  • #2
    Originally posted by Jeff Lee
    The command object is usually a one-to-one relationship with the Form Controller and Validator.

    On one hand, the command class can be hard coded in the Controller/Validator such as:
    Code:
    public MyController extends SimpleFormController {
      public Object formBackingObject() {
        MyForm command = new MyForm();
        command.setYada(yada);
        ...
        return command;
      }
    }
    On the other hand, the command class can be injected such as:
    Code:
    <bean id="MyController" class="com...MyController">
      <property name="commandClass" value="com...MyForm"/>
      <property name="commandName" value="myform"/>
    </bean>
    Can someone list off some advantages to wiring the commandClass instead of just leaving it hard coded?
    Typically you'll see the controller is also coupled to the command class, making is absolutely sensible to set the commandClass property in the controller constructor.

    Originally posted by Jeff Lee
    As well, are there useful situations where you want to rename the commandName from "command" to "myform"?
    The command name is probably more likely to vary. Anyhow, you can still set its value in the constructor - or use the default - and overwrite the property value whenever necessary.

    Comment


    • #3
      I'm looking for more if a "best practice" answer.

      Why set the command class when the application works fine hard coded?

      Why rename the command to something else when the word "command" is just fine?

      Comment


      • #4
        setCommandClass() is for the simplest scenarios where the form just needs to be backed by a new instance - for example, one of those New XXX forms. You have to use formBackingObject() for pretty much everything else - e.g., loading the command object from the DB, etc.

        Comment

        Working...
        X