JCatapult MVC forms that post to different URIs fail

[GoogleCodeExporter]

It is a common pattern to have a URI such as:

  /sticky-note/details

This URI often contains a form that allows users to manipulate other
objects that are part of a sticky note such as comments. This often looks
like this in the FTL file:

  [@jc.form action="/sticky-note/comment/add"]
    [@jc.text name="comment.text"/]
    [@jc.submit name="add"/]
  [/@jc.form]

In the current version of the MVC, this page will not render. The reason is
that the /sticky-notes/details action doesn't have a field named *comment*.
The MVC form tags (text, textarea, etc) currently throws exceptions when
the current action doesn't have a valid property for them.

There are two ways to fix this situation:

  1. Remove the constraint from the tags

  2. Provide a tag called [@jc.action] that will execute a GET request to
the URI /sticky-note/comment/add to render the form

  3. Use AJAX on the client to dynamically send a GET request to the URI
/sticky-note/comment/add to render the form into the current DOM

JCatapult MVC currently supports only #3. We can either support both #1 and
#2 or just one of them. I'm leaning towards #2 only because it is
semantically correct and correctly localizes the form to the URI it is
associated with and leaving the exception handling in the tags.

Original issue reported on code.google.com by bpontare...@gmail.com on 1 Aug 2008 at 11:57

[GoogleCodeExporter]

Original comment by leafkn...@gmail.com on 10 Sep 2008 at 8:13

• Added labels: Milestone-1.0-RC8
• Removed labels: Milestone-1.0-RC7

[GoogleCodeExporter]

This is fixed now. When a form is being rendered, all of the properties are 
verified
against the action that maps to the URI of the form. Likewise, all localized 
messages
are now pulled from the bundle associated withe the URI of the form, not the 
current URI.

Therefore, we no longer need to support #1 or #2, both of which were pretty 
hacky. #2
could be an enhancement in the future, but shouldn't be used for forms, since 
most
action's will result in full HTML DOMs. That would make #2 render an invalid 
HTML or
XHTML result.

Original comment by bpontare...@gmail.com on 14 Sep 2008 at 9:50

• Changed state: Fixed