Just realised I accidentally sent this to Mike directly instead of the list.
On 29 Jan 2008, at 23:17, Mike Orr wrote: > > On Jan 29, 2008 2:55 PM, Steven Holmes <[EMAIL PROTECTED]> wrote: > >> 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. > > I don't see why it matters that an error form is displayed at a > different URL than the original form, especially since it's a > temporary transition step (not something to bookmark). But point > taken that the same URL could route to two different methods depending > on the HTTP action. It matters for two reasons: It's exposing an implementation detail to the user (they don't give a damn that internally the form is using two methods). It's also inconsistent. Why *shouldn't* a user bookmark a URL to edit their account? And why would the user expect two pages that display the same form to act so differently--one being bookmarkable, one not being bookmarkable. It's just unnecessarily confusing. They don't care if the step is a transition step or not, and they certainly shouldn't have to care. And what will happen if the user clicks return in the address bar and reloads the page with a GET? It breaks. It's just a Bad Way Of Doing Things. There are no advantages to it that I can see. >> 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). > > I assume you mean "/account/id/delete". > > That's what I've been doing too. I've been trying to port my pages > to map.resource to be REST-ly correct, but I'm starting to think this > is not necessary for things like accounts that will never be > syndicated. Yeah, I meant /account/id/delete Cheers, Steven --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
