On Jan 29, 2008 2:55 PM, Steven Holmes <[EMAIL PROTECTED]> wrote: > > > On 29 Jan 2008, at 18:51, Mike Orr wrote: > > > > @validate is another issue. It's a nice convenience but it does limit > > what you can do in your code. Going to a one-method scheme would > > require it to be bypassed or rewritten in the application. I've also > > found another problem in that the forms I'm porting to Pylons have a > > Cancel button, which is supposed to bypass the validators and do a > > redirect. I'd either have to have a big OR validator around all the > > others, or wrap or rewrite @validate to process "cancel" before > > executing the validators. > > > > So, I think the Pylons docs need to mention @rewrite's limitions and > > show how to work around them (calling the validators manually in the > > action), and perhaps also show the one-method technique. However, I'm > > not sure the one-method technique will be supported by map.resource, > > though you can use arguments to get something approaching that. > > I'm not sure what you mean by one-method scheme.
I meant having the same controller method both display the form and process it. This is how some other frameworks do it, and what I thought you wanted. The method would need an "if" to distinguish whether there's form input, and another to distinguish whether there were errors. I forgot that @validate without the form= argument would call the original method, so it should work in a one-method scenario after all. > 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. > 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. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
