Rails - Mar 2006 - alternative form processing pattern

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

Xavier Noria napisa?(a):
> 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
No there are no drawbacks. In fact, CD Baby.com uses the same approach.