Alternative form processing pattern


#1

Scaffolds generate new/create-like pairs to process forms. +new+
renders the form, and +create+ process it. If successful +create+
redirects to some view with no side-effects like +show+.

Now, if +create+ fails, we usually render :action => ‘new’ to present
the form again together with error messages. Albeit being the reponse
to a POST request the browser then changes the URL in the navigation
bar from “…/new” to “…/create”. Both Safari and Firefox do that.

I don’t like that mixture of actions in the navigation bar. I could
prevent +create+ from responding to GET requests, in case browser
completion hits that cached URL, but am thinking everything would be
cleaner if +new+ could handle both rendering and processing.

If I delete +create+ and program +new+ so that it renders the form in
response to GET, and process the form in response to POST, everything
looks easier AFAICT and the URL stays the same if validation fails.
Do you foresee any drawback in that pattern? Does anybody use it?

– fxn


#2

Xavier N. napisaÅ?(a):

prevent +create+ from responding to GET requests, in case browser
completion hits that cached URL, but am thinking everything would be
cleaner if +new+ could handle both rendering and processing.

If I delete +create+ and program +new+ so that it renders the form in
response to GET, and process the form in response to POST, everything
looks easier AFAICT and the URL stays the same if validation fails. Do
you foresee any drawback in that pattern? Does anybody use it?

– fxn

No there are no drawbacks. In fact, CD Baby.com uses the same approach.