Lukas, I agree on the method names, but there is an important piece you missed:
I think that setForward() method should behave the same way in html and xml/json formats. That is - if I setForward() some route after user was created, that would should the newly created user - it would show it in xml/json and also would return new user profile page in html Best, On Wed, Dec 1, 2010 at 10:02 AM, Lukas Kahwe Smith <[email protected]>wrote: > > 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]<symfony-devs%[email protected]> > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- *Bulat Shakirzyanov* | Software Alchemist *a: *about.me/avalanche123 *e:* [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
