I am about automatic evaluation support based on the mime-type. I know that i can do everything i want by hand...of course.. but that ain't automatic.
Secondly, there is no point for X-JSON to be a status message carrier or "just for simple stuff". Drop it entirely. It's is unnecessary. Most people will have an own error format / object notation which they transport in the responseText as a replacement for the expected content and act on it. (eg include a "status" key) This two-way devlivery is just complicating things. And lastly, the thing i am pointing at is, that prototype does not automaticly evaluates responseText if X-JSON header was found, forcing me to evaluate by hand.. A server should always deliver, regardless if error or data. With that in mind, i don't need a X-JSON header to tell me that everything is alright and that i could now go ahead and eval responseText. Thats why i suggest automatic evaluation of responseText if the content-type is application/json. Simple.. just like text/xml, just like text/javascript .. Regards On 1/20/07, David Z�lke <[EMAIL PROTECTED]> wrote: > > You're missing the point of the X-JSON header (which doesn't have > anything to do with the content type). The idea is that the response > body returns data like an HTML fragment, and the X-JSON header > carries status information like "operation successful" or "operation > failed", or other simple code that contains rudimentary logic to go > with the actual content delivered in the response body. > If you want to pass back JSON only to the client, do so in the > response body, and eval by hand. > > David > > P.S.: http://www.ietf.org/rfc/rfc4627.txt?number=4627 > > > Am 19.01.2007 um 23:32 schrieb Kjell Bublitz: > > > > > While looking thru the brand new documentation i found myself > > stumbling upon the X-JSON header "again" as being suggested for > > automatic json evaluation within prototype. > > > > I must say that this approach is bad. We should evaluate on content > > type. It is simple to add and i wonder why no one else did it already. > > > > The content-type "text/x-json" is the closest acceptable description > > according to the RFCs and should be used by prototype to determine if > > evaluation is in order. Just like text/javascript, which is > > implemented already. > > > > The whole reason behind this is, that a header line is limited to a > > specific size. So if youre JSON data is to huge, the server will > > return nothing (or refuse delivery.. i dont know exactly what happens > > in the background - browser or server). I expirienced this in a > > PHP/Apache enviroment. > > > > We should stick to content types instead of "inventing" new headers > > which are limited in size anyways.. > > > > This is what i added to make it work: > > > > evalJSONResponse: function() { > > try { > > return eval('(' + this.transport.responseText + ')'); > > } catch (e) {} > > }, > > > > respondToReadyState ... > > [...] > > if (this.header('Content-type') == 'text/x-json') > > json = this.evalJSONResponse(); > > > > > > Opinions? > > > > -- > > Kjell > > -- www.m3nt0r.de > > > > > > > > > > > > -- Kjell --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
