On 29 Jan 2008, at 18:51, Mike Orr wrote:

I'm not sure what you mean by one-method scheme.

What I was suggesting for @validate would still have two methods on the controller, one for form processing and one for displaying the form. It's just these would be accessed at the *same* URL, being differentiated by whether it was POST or a GET.

This is exactly what happens now when re-submitting a form that didn't validate... the form is redisplayed at, say, /account/create and also POSTed to /account/create. The difference is that there is an extra / account/create_form URL through which the form is accessed initially. What good does this extra URL do? As far as I can tell, none. So what I'm proposing isn't fundamentally different from what happens already with @validate, and it's not using any techniques that are not already used in the current @validate.

Regarding URLs, I only have the very vaguest idea of what REST is. Much like Matt, I structure my URLs like this:

/account/create <-- Create an account (GET displays the form, POST creates the account and redirects to /account/id) /account/id <-- Displays the account details /account/id/edit <-- Edit account details (similar to /account/create) /account/delete <-- Deletes the account (GET gives a form asking confirmation, POST does the deletion).

This has worked very well for me so far.

Cheers,

Steven