Martin, I disagree with your handling of parameters. As previously stated, I believe the X-JSON header handling should be left intact, as-is, both for backwards compatibility, and because it is still useful as a separate feature. The Content-type header detected as "application/json" should be an entirely new feature and be implemented via a property set in the transport. (e.g. transport.responseJSON) See my previous post for further reasoning and explanation. Several people have agreed with this and I see no reason not to handle it this way.
Cheers, Colin Martin Bialasinski wrote: > If content-type is application/json: > - a possible X-JSON header is disregarded. > - the responseText is eval'd via string.evalJSON() > transport.responseJSON is set to the returned value, thous it is > * an Object, if evalJSON() succeeds > * null, if evalJSON() fails because the eval() failed > * null, if sanitize was requested and the data did not pass > > Question: should failing the sanitize process in evalJSON() > trigger onException? I believe yes. > > If content-type is not application/json: > (only the X-JSON part) > - the X-JSON header is eval'd via string.evalJSON() > transport.responseJSON is set to the returned value, thous it is > * an Object, if evalJSON() succeeds > * null, if evalJSON() fails because the eval() failed > * null, if sanitize was requested and the data did not pass > > Result: > transport.responseJSON always contains the JSON object returned (if > there was any), regardless how it was transported. > > Question: > The callbacks get a parameter list of (transport, json). The json > parameter is not needed any more, if transport.responseJSON is used > consistently, but we cannot let it go for compatibility reasons. > > If If content-type is not application/json, json gets its value from > the X-JSON header. > If If content-type is application/json, should it gets its value from > from the responseText? > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" 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/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
