I'll admit at the forefront, I'm not a fan of the extreme 'restification' of the web the way the rails evangelists and followers have pushed for, or the 'restful web services' crowd.
http is the transport protocol. its in the name -- "Hypertext Transfer Protocol" throwing a 400 on a form error is confusing to many. oauth and openid can use it, because they're creating new protocols based on mapping http stuff. oauth and openid are interpreting the 400x as something specific. if you want your app to do the same, then fine -- raise a custom redirect or set the error code yourself. it's not that hard. a large majority of people want/expect 200 for form errors. i'm all for allowing people to handle @validate better with more keywords. i've been pushing for a bunch myself -- I just don't like the idea of it being the 'new' thing as in 'backwards' compatible. i think 'forwards compatible' is a better sentiment. question though -- what if the @validate received the right params, but there was a db error or some other server error. does that become another 4xxx code in your system, or are they all lumped into the same concept. how are those instances translated into the @validate decorator? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
