On 01.12.2010, at 15:33, Bulat Shakirzyanov wrote: > Hi Lukas, > > I have already mentioned this in IRC conversation we had yesterday. > I have two main problems with this approach: > • Consistency violation > • Consistency violation > Let's look at browser user registration example: > • User gets an html form - GET /users/new > • User fills the form and submits - POST /users > • If submit successful - goto 5 > • If submit failed - display form with validation errors in response. > • Redirect user to new user Location with response: Location: /users/1 > Now let's convert that use case to json/xml rpc: > • User reads docs about the format of new user resource > • Users issues create user request - POST /users > • If resource created - goto 5 > • If resource creation fails - return 5** response with optional body > • Return 201 response with Location: /users/1 - to show location of > newly created response > Now the browser case seems consistent with your proposal, so let's compare > your rpc example: > • User reads docs about the format of new user resource > • Users issues create user request - POST /users > • Return response with new user resource or with validation error > As you can see - the rpc case is completely different from browser case. > Again, I am not saying that my suggested way of doing things is the only > correct way. > You could of course implement the same steps you have in rpc example in > browser: > • User gets an html form - GET /users/new > • User fills the form and submits - POST /users > • Return user account page of failed form with error messages > One could argue at this point that we save ourselves a round-trip to the > server if treat browser differently > I could argue that given proper http cache implementation on the server - you > actually save yourself > caching trouble as the /users/1 url would get cached in your reverse proxy > mechanism and browser > > I think that introducing inconsistencies as such would only cause more > misunderstandings > and frustration for the users of the framework.
setExternalRedirect() is intended to behave in a consistent manner and we did our best implementing it in such a way. we were not aware of standard Ajax libraries to support http redirects, which is why we opted to just return the url in some admittedly random format. but again, with setExternalRedirect() the developer should have the tools for a consistent redirect regardless of the format. however the reality is that the behavior implemented in setRedirect() covers how API's have been build in the past. just without the format specific code in the controller. > Please note, that I am not against forward functionality - I just think it > should work in a consistent > was, no matter what your target client is - less magic = more goodness well it seems to be like you are against the "magic" forward functionality, which is the key feature we are talking about here. > Also I agree, that having a convenience method to redirect to action without > having to generate the url > manually ourselves is a worthy addition so in other words you would prefer to rename: s/setRedirect/setForward s/setExternalRedirect/setRedirect regards, Lukas Kahwe Smith [email protected] -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" 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/symfony-devs?hl=en
