On Jan 29, 2008 9:40 AM, Ian Bicking <[EMAIL PROTECTED]> wrote: > > Matt Feifarek wrote: > > Yes, we're disagreeing on what the default should be. Well, you'll > > have to convince Ben. I think he likes it the other way. > > > > > > I don't have this particular religion, but what would a REST zealot say? > > Seems like two different URI's for the same thing is bad. > > REST zealots say that you should have: > > GET /resource -> rendered thing > GET /resource/edit -> form > POST /resource -> make the change > > So there is generally another URL involved. But REST zealots don't deal > with HTML forms.
This gets into how Pylons should support REST, and what this implies for the changes I'm making in Routes 2. Ben and I discussed map.resource a week ago, and he said it follows the Atom Publishing Protocol, a widely-respected REST spec. I haven't studied it yet but here are some links on it. http://tools.ietf.org/html/rfc5023 http://www.ibm.com/developerworks/library/x-atompp1/ As a recap, map.resource believes that: GET /messages => display index page POST /messages => create new message GET /messages/new => display add form (action = POST /messages) GET /messages/1 => display message 1 GET /messages/1/edit => display edit form (action = PUT /messages/1) PUT /messages/1 => modify message 1 DELETE /messages/ 1 => delete message 1 (Routes 1 has ";edit" instead of "/edit", but Ben said that's an invalid URL syntax borrowed from Rails, which Rails has since corrected.) PUT and DELETE are implemented by an "_action" query param to a POST form, which Routes notices and changes the request method. Again, Ben says this is widely done in other programming languages. Atom specifies the URLs, not the controller methods. So we could rename the actions or merge the form-submission ones. But I'm wary of making such a big change for such a small benefit. One problem I've come across is the lack of a delete confirmation form. Ben says you can do it in Javascript before the DELETE executed, but I need something that degrades if users don't have Javascript. It looks like " GET /messages/1/delete" would nicely fit into that scheme. @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. -- 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 -~----------~----~----~----~------~----~------~--~---
