Announcement Announcement Module
Collapse
No announcement yet.
Why even bother with commandName? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Why even bother with commandName?

    The Spring Framework documentation states in passing that naming your command something other than the default "command" is a best practice:

    http://static.springframework.org/sp...taglib-formtag

    Why is this? My experience working with a very large application with several hundred controllers and about 20 different commandNames used in different modules, is that using custom commandNames is a net loss.

    I can't reuse JSPs or portions of JSPs because the command name is hardcoded into them, binding the JSP to one system module - or worse, one specific controller.

    Using a decorator such as SiteMesh to take care of common tasks like error message display becomes a hairball problem.

    Honestly, I haven't seen anything that would count as a win for setting commandName. Given the existence now of the <form:form /> tag, I don't know why the commandName property even exists anymore. The form tag should just reference the command object. It should *know* what the command object is without being told. Same with the errors tag.

    Anyway, if someone can give me a compelling justification for setting the commandName property on a form controller, please do so.

  • #2
    Use a small piece of reflection to get the member variable name into your model with a 'standard' name (forms.commandName in this case) and use this code in your jsp:

    Code:
    <form:form commandName="<c:out value="${forms.commandName}">
    Your commandName can change as you like but it will always bind correctly. This also works if your view renders from more than one controller with different commandNames.

    Comment


    • #3
      Originally posted by John Vance View Post
      The Spring Framework documentation states in passing that naming your command something other than the default "command" is a best practice:

      http://static.springframework.org/sp...taglib-formtag

      Why is this? My experience working with a very large application with several hundred controllers and about 20 different commandNames used in different modules, is that using custom commandNames is a net loss.
      The only sensible scenario I can think of where custom command names are necessary is when you have multiple forms on one page and each of them binds to a different command object. In all other usual cases, "command" has worked well for me. Readability doesn't seem to be an issue. After all, if I'm looking at one whole form bound to various properties of Customer, I woundn't need the command name to be explicitly "customer" for a reminder.

      Comment


      • #4
        Thanks all

        Manifoldronin, that's pretty much what I thought. I've posted an enhancement request for SpringWeb to make the form tag aware of which object in the model is the command object. The only time you would need to set commandName would be when you're specifying an object that isn't the current command object, as in your multiple form example.

        jonnio, thanks for the tip. I had been dropping the command name directly into the request using some nasty code in an interceptor. I'd considered rewriting SimpleFormController.showForm() to add this line:

        model.add("formname", this.getCommandName());

        I'll look into using reflection or perhaps an AOP advice on showForm() to accomplish that.
        Last edited by John Vance; Oct 4th, 2006, 04:17 PM. Reason: posted by accident before finishing.

        Comment


        • #5
          John,

          I'd like to add, though, a lot of people (including myself) are not using <form:form/>. I'm pretty happy with spring:bind so far. So I - we - still need commandName. I was just saying I wouldn't bother changing the default name.

          Comment

          Working...
          X