Grails
  1. Grails
  2. GRAILS-9888 REST and URL mapping changes
  3. GRAILS-2843

Form tag doesn't generate correct URL when REST-ful HTTP protocol is used

    Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.0.2
    • Fix Version/s: 2.3-M2
    • Component/s: TagLib, URL mappings
    • Labels:
      None

      Description

      For simple URL mapping, such as

       
       "/test/action"(controller: "test", action="action"){}
      

      The form tag url could correct translate the link to /test/action

      However, when the URL mapping contains different action for different HTTP method, the form tag url attribute doesn't translate the url and http method correctly. e.g. For the following mapping:

       
       "/test/action"(controller: "test") { action = [GET: "action1", POST: "action2"]  }
      

      In the following form:

       
      <g:form name="myform" url="[action:'action1',controller:'test']">
        <g:submitButton name="Submit" value="action1"/>    
      </g:form>
      

      i expect it should translate to:

       
      <form action="/test/action" method="get"> 
      

      but it is now translated to :

       
      <form action="/test/action1"> 
      

        Issue Links

          Activity

          Hide
          Graeme Rocher added a comment -

          I don't understand what the issue is here. Yes I see that when you specify the action it translates the link incorrectly, however you should not specify the action when using restful requests. A form definition like:

          <g:form name="myform" url="[controller:'test']">
            <g:submitButton name="Submit" value="action1"/>    
          </g:form>
          

          will work fine, and if you need to change the action you go to you modify the HTTP method as follows:

          <g:form name="myform" method="GET" url="[controller:'test']">
            <g:submitButton name="Submit" value="action1"/>    
          </g:form>
          
          Show
          Graeme Rocher added a comment - I don't understand what the issue is here. Yes I see that when you specify the action it translates the link incorrectly, however you should not specify the action when using restful requests. A form definition like: <g:form name= "myform" url= "[controller:'test']" > <g:submitButton name= "Submit" value= "action1" /> </g:form> will work fine, and if you need to change the action you go to you modify the HTTP method as follows: <g:form name= "myform" method= "GET" url= "[controller:'test']" > <g:submitButton name= "Submit" value= "action1" /> </g:form>
          Hide
          Mingfai Ma added a comment -

          noted. I think the 2nd piece of code is a valid workaround to me. i suppose the purpose of reverse lookup in the url mapping to avoid hardcoding. If I have a RESTful API that has POST and GET for two actions, I would expect to define the action in the form and let the "method" be generated and I don't need to hard code the method (which is duplicated in the urlmapping). So if I change the HTTP method in the UrlMapping, i don't need to make change to the forms. (i.e. for the same purpose of the url attribute.)

          if it's too complex to implement, or you guys think it's no good to implement, I think it should be stated in the documentation.

          ps is "however you should not specify the action when using restful requests" is a good practice or what? if it's just a design preference, then I think the implementation should give the flexibility to allow people to directly call the restful action. Take an example, I may use Grails to implement a restful API for an external application and also for a local Grails form to use. I would want to avoid hardcoding the HTTP method.

          pps HTML form should support POST and GET only. this could be a reason to skip the HTTP method lookup. I personally would prefer to do lookup if an action is mapped to POST or GET, and leave the method blank (that default as GET) for other cases.

          Show
          Mingfai Ma added a comment - noted. I think the 2nd piece of code is a valid workaround to me. i suppose the purpose of reverse lookup in the url mapping to avoid hardcoding. If I have a RESTful API that has POST and GET for two actions, I would expect to define the action in the form and let the "method" be generated and I don't need to hard code the method (which is duplicated in the urlmapping). So if I change the HTTP method in the UrlMapping, i don't need to make change to the forms. (i.e. for the same purpose of the url attribute.) if it's too complex to implement, or you guys think it's no good to implement, I think it should be stated in the documentation. ps is "however you should not specify the action when using restful requests" is a good practice or what? if it's just a design preference, then I think the implementation should give the flexibility to allow people to directly call the restful action. Take an example, I may use Grails to implement a restful API for an external application and also for a local Grails form to use. I would want to avoid hardcoding the HTTP method. pps HTML form should support POST and GET only. this could be a reason to skip the HTTP method lookup. I personally would prefer to do lookup if an action is mapped to POST or GET, and leave the method blank (that default as GET) for other cases.
          Hide
          Graeme Rocher added a comment -

          that "however you should not specify the action with restful requets" statement is now up for debate following conversations with other G2One'ers. I think we can find a solution I'm just not sure what it is right now.. we'll bring it up on the mailing list sometime in the near future

          Show
          Graeme Rocher added a comment - that "however you should not specify the action with restful requets" statement is now up for debate following conversations with other G2One'ers. I think we can find a solution I'm just not sure what it is right now.. we'll bring it up on the mailing list sometime in the near future
          Hide
          Graeme Rocher added a comment -

          There is no scope / time to resolve these remaining lower priority issues for 1.2 so moving to 1.3

          for 1.2 final only issues considered blocking will now be fixed

          Show
          Graeme Rocher added a comment - There is no scope / time to resolve these remaining lower priority issues for 1.2 so moving to 1.3 for 1.2 final only issues considered blocking will now be fixed
          Hide
          cdeszaq added a comment -

          The form tag should be able to determine it's method based on the action<->HTTP Method mappings. Of course, not all HTTP methods are valid form methods (I think only GET and POST are allowed), but the form tag should be able to resolve that correctly fro the controller and action it's given and the URL mappings.

          Especially with more REST support, issues like this become more important.

          Show
          cdeszaq added a comment - The form tag should be able to determine it's method based on the action<->HTTP Method mappings. Of course, not all HTTP methods are valid form methods (I think only GET and POST are allowed), but the form tag should be able to resolve that correctly fro the controller and action it's given and the URL mappings. Especially with more REST support, issues like this become more important.
          Hide
          Peter Ledbrook added a comment -

          In addition to the GRAILS-8945 changes, this issue effectively asks the <g:form/> tag to set the method attribute appropriately based on the controller action requested.

          Show
          Peter Ledbrook added a comment - In addition to the GRAILS-8945 changes, this issue effectively asks the <g:form/> tag to set the method attribute appropriately based on the controller action requested.

            People

            • Assignee:
              Graeme Rocher
              Reporter:
              Mingfai Ma
            • Votes:
              5 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Last Reviewed:

                Development