Forum: Rails Spinoffs (closed, excessive spam) About X-JSON header and evil things... ;)

F72d844cd647e3a0b36255724bfd9c9f?d=identicon&s=25 Kjell Bublitz (m3nt0r)
on 2007-01-19 23:33
(Received via mailing list)
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
4dae3b057d62f103f56d2c5d58007a08?d=identicon&s=25 Ryan Gahl (Guest)
on 2007-01-19 23:41
(Received via mailing list)
This makes a lot of sense to me.

On 1/19/07, Kjell Bublitz <m3nt0r.de@gmail.com> wrote:
> according to the RFCs and should be used by prototype to determine if
> which are limited in size anyways..
> [...]
> >
>


--
Ryan Gahl
Application Development Consultant
Athena Group, Inc.
Inquire: 1-920-955-1457
Blog: http://www.someElement.com
Eea3feaacbe44706164289d068d94828?d=identicon&s=25 Peter Michaux (Guest)
on 2007-01-20 00:41
(Received via mailing list)
On 1/19/07, Kjell Bublitz <m3nt0r.de@gmail.com> wrote:
> evaluation is in order. Just like text/javascript, which is
> implemented already.

Why "text/x-json" and not "application/json" which is the approved
JSON mime-type?

Peter
--
JavaScript for Rails: http://forkjavascript.org
F72d844cd647e3a0b36255724bfd9c9f?d=identicon&s=25 Kjell Bublitz (m3nt0r)
on 2007-01-20 00:45
(Received via mailing list)
Hi Peter

None of theme are approved, but according to the RFC, the text-tree is
closest one when it comes down to properly describing the content. You
put everything into "application" that is too specific or "does not
fit into any of the other categories"

Kjell

On 1/20/07, Peter Michaux <petermichaux@gmail.com> wrote:
> > The content-type "text/x-json" is the closest acceptable description
>
> >
>


--
Kjell
-- www.m3nt0r.de
F72d844cd647e3a0b36255724bfd9c9f?d=identicon&s=25 Kjell Bublitz (m3nt0r)
on 2007-01-20 00:48
(Received via mailing list)
Just for reference towards discussion, here a quote from the RFC:

".4. The Application Content-Type

The "application" Content-Type is to be used for data which do not fit
in any of the other categories, and particularly for data to be
processed by mail-based uses of application programs. This is
information which must be processed by an application before it is
viewable or usable to a user. "

http://www.faqs.org/rfcs/rfc1521.html

Thats why i chose "text/x-json" over "application/x-json". It is
readable text, after all

Kjell


On 1/20/07, Kjell Bublitz <m3nt0r.de@gmail.com> wrote:
> >
> > > according to the RFCs and should be used by prototype to determine if
> > > >
> >
>
>
> --
> Kjell
> -- www.m3nt0r.de
>


--
Kjell
-- www.m3nt0r.de
Eea3feaacbe44706164289d068d94828?d=identicon&s=25 Peter Michaux (Guest)
on 2007-01-20 01:49
(Received via mailing list)
On 1/19/07, Kjell Bublitz <m3nt0r.de@gmail.com> wrote:
>
> Hi Peter

[Re official JSON mime-types]

> None of theme are approved,

From Douglas Crockford himself

<URL: http://tech.groups.yahoo.com/group/json/message/337>

Peter
--
JavaScript for Rails: http://forkjavascript.org
0db9fec6cfc257aa9daa75f20ba1e625?d=identicon&s=25 Colin Mollenhour (Guest)
on 2007-01-20 01:57
(Received via mailing list)
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
This is a *great* idea in my opinion. I myself have experienced the
size limitations of the X-JSON header before.&nbsp; However, I don't see
why
there can't be support for both so that backwards compatibility isn't
broken. Programmers would just have to know that you can't use them
both simultaneously. That said, I wouldn't mind seeing X-JSON replaced
with Content-type but it would mean hours of going back and changing
code.<br>
<br>
Colin<br>
<br>
Kjell Bublitz wrote:
<blockquote
 cite="mid:5bfa46320701191547x47d1c781w5ac31fdeaab1d29a@mail.gmail.com"
 type="cite">
  <pre wrap="">Just for reference towards discussion, here a quote from
the RFC:

".4. The Application Content-Type

The "application" Content-Type is to be used for data which do not fit
in any of the other categories, and particularly for data to be
processed by mail-based uses of application programs. This is
information which must be processed by an application before it is
viewable or usable to a user. <a class="moz-txt-link-rfc2396E"
href="http://www.faqs.org/rfcs/rfc1521.htmlThatswhyichos...

http://www.faqs.org/rfcs/rfc1521.html

Thats why i chose "</a>text/x-json" over "application/x-json". It is
readable text, after all

Kjell


On 1/20/07, Kjell Bublitz <a class="moz-txt-link-rfc2396E"
href="mailto:m3nt0r.de@gmail.com">&lt;m3nt0r.de@gmail.com&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi Peter

None of theme are approved, but according to the RFC, the text-tree is
closest one when it comes down to properly describing the content. You
put everything into "application" that is too specific or "does not
fit into any of the other categories"

Kjell

On 1/20/07, Peter Michaux <a class="moz-txt-link-rfc2396E"
href="mailto:petermichaux@gmail.com">&lt;petermichaux@gmail.com&gt;</a>
wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">On 1/19/07, Kjell Bublitz <a
class="moz-txt-link-rfc2396E"
href="mailto:m3nt0r.de@gmail.com">&lt;m3nt0r.de@gmail.com&gt;</a> wrote:
      </pre>
      <blockquote type="cite">
        <pre wrap="">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.
        </pre>
      </blockquote>
      <pre wrap="">Why "text/x-json" and not "application/json" which is
the approved
JSON mime-type?

Peter
--
JavaScript for Rails: <a class="moz-txt-link-freetext"
href="http://forkjavascript.org">http://forkjavascript.o...

      </pre>
    </blockquote>
    <pre wrap="">
--
Kjell
-- <a class="moz-txt-link-abbreviated"
href="http://www.m3nt0r.de">www.m3nt0r.de</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
<br>
--~--~---------~--~----~------------~-------~--~----~<br>
You received this message because you are subscribed to the Google
Groups &quot;Ruby on Rails: Spinoffs&quot; group. <br> To post to this
group, send email to rubyonrails-spinoffs@googlegroups.com <br> To
unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe@googlegroups.com <br> For more options,
visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en <br>
-~----------~----~----~----~------~----~------~--~---<br>
</body>
</html>

<br>
F72d844cd647e3a0b36255724bfd9c9f?d=identicon&s=25 Kjell Bublitz (m3nt0r)
on 2007-01-20 01:59
(Received via mailing list)
Oooh .. application/json then... also i can't aggree on this decision,
as stated in my previous post. It is not binary, it is text.

But i dont work for IANA, so be it..

(back to topic)

Since this is a official mime, there is more need to leave the
"X-JSON" path and move towards application/json.. content-type should
be enough to negotiate eval.




On 1/20/07, Peter Michaux <petermichaux@gmail.com> wrote:
>
> <URL: http://tech.groups.yahoo.com/group/json/message/337>
>
> Peter
> --
> JavaScript for Rails: http://forkjavascript.org
>
> >
>


--
Kjell
-- www.m3nt0r.de
353320c19b93ee4a04dc945f02957106?d=identicon&s=25 David Zülke (Guest)
on 2007-01-20 15:44
(Received via mailing list)
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:
F72d844cd647e3a0b36255724bfd9c9f?d=identicon&s=25 Kjell Bublitz (m3nt0r)
on 2007-01-20 16:28
(Received via mailing list)
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 <dz@bitxtender.com> wrote:
> David
> >
> > return nothing (or refuse delivery.. i dont know exactly what happens
> >         return eval('(' + this.transport.responseText + ')');
> >
> > --
> > Kjell
> > -- www.m3nt0r.de
> >
> > >
> >
>
>
> >
>


--
Kjell
8f93a872e399bc1353cc8d4e791d5401?d=identicon&s=25 Mislav MarohniÄ? (mislav)
on 2007-01-22 13:43
(Received via mailing list)
Will be done:
http://dev.rubyonrails.org/ticket/7295

In future, start discussions about core changes in the Core group.
Thanks!

--
Mislav
A5c2cf0ecee0dc7b1663856892ade523?d=identicon&s=25 Dave Crane (Guest)
on 2007-01-22 15:29
(Received via mailing list)
On Saturday 20 January 2007 15:22, Kjell Bublitz wrote:
> 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)
>
My reading of the X-JSON header was that it's useful in cases where you
want
to pass some secondary data back with a response. The practice of
'piggy-backing' data in this way isn't to everybody's taste, but it can
be a
useful way of avoiding extra traffic.

Rails & Prototype both have a strong bent towards delivering fragments
of HTML
rather than data in the response. In this case, If you're sending back
content, I don't see how to easily embed secondary data inside the main
response body, other than stuffing it into a hidden DIV, which loses
several
hundred points for elegance. Sure, if you're delivering data anyway,
X-JSON
isn't particularly useful.

On Monday 22 January 2007 12:42, Mislav wrote:
> Will be done:
> http://dev.rubyonrails.org/ticket/7295
Just saw this come in on the list - sounds like a good suggestion to me.



Just my $0.02

Dave
--
----------------------
Author
Ajax in Action http://manning.com/crane
Ajax in Practice http://manning.com/crane2
Prototype & Scriptaculous Quickly http://manning.com/crane3
A5384633e46b492b4275a03f7d62de20?d=identicon&s=25 Alexander Presber (Guest)
on 2007-01-22 16:42
(Received via mailing list)
Am 22.01.2007 um 13:46 schrieb Dave Crane:

> My reading of the X-JSON header was that it's useful in cases where
> main
> response body, other than stuffing it into a hidden DIV, which
> loses several
> hundred points for elegance. Sure, if you're delivering data
> anyway, X-JSON
> isn't particularly useful.

Just want to support that opinion. We are using the X-JSON header
exactly for that.

Alex
648805ae18e92b7c71e46f3caa23ddc8?d=identicon&s=25 Ed C. (Guest)
on 2007-01-22 16:58
(Received via mailing list)
This seems like almost a duplication of effort -- we already have access
to
the HTTP status codes, which could (should?) be used to determine
success
(example, 200 = OK, 500 = Error). The content body includes the results
or
error message(s).
8f93a872e399bc1353cc8d4e791d5401?d=identicon&s=25 Mislav MarohniÄ? (mislav)
on 2007-01-22 17:34
(Received via mailing list)
Let us get something clear - the X-JSON header is a hack. Nothing
serious,
just a small hack which simplifies returning two types of data (HTML and
application/json) at the same time. Of course we're using HTTP headers
in a
way we shouldn't, but has anyone seen how multipart-encoded message look
like? Our header hack is way nicer and technically simpler than that
kind of
encoding.

The X-something headers are reserved for custom (proprietary) usage. We
have
the freedom to use them in any way we want to, and we have taken that
liberty to do some highly conventional JSON magic.

For big loads of JSON data you'll want to use response body. The ticket
I
submitted (and for which I'll provide a patch for) will enable that.

Ed C.: yeah, HTTP status messages could be extracted and shown in this
case,
but X-JSON chunks are used for much more than that. I use them regularly
to
return small hashes representing certain records or other objects.

--
Mislav
0db9fec6cfc257aa9daa75f20ba1e625?d=identicon&s=25 Colin Mollenhour (Guest)
on 2007-01-22 17:47
(Received via mailing list)
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
This change, while I think is a good idea in general, will be somewhat
difficult to make use of if the new JSON object replaces the old JSON
object.<br>
I, and apparently others, use X-JSON often for error checking, debug
messages, status flags, etc..&nbsp; When your application requires the
occasional use of raw HTML and you don't want to encode it all in a
JSON message, it is very useful. However, I still use JSON encoded data
in the response body because of the size limitations of the X-JSON
header.<br>
Having X-JSON *replaced* by the evaluated responseText, will make it
difficult for when I want to still use the X-JSON header for
error/debug/status info, but send the main response body as either
plain X-HTML or JSON due to the size limit.<br>
<br>
To make it more clear, I would have to account for the following
possible scenarios on the server side in order to make use of the new
feature:<br>
1) If response is HTML then error/debug is X-JSON<br>
2) If response is JSON then error/debug is in response JSON<br>
<br>
It would be nice if the body JSON didn't replace the X-JSON because
then I could always use X-JSON for error/debug regardless of what is in
the responseText.<br>
This just seems like better separation of data and error/status
handling to me. <br>
<br>
My suggestion is perhaps rather than replacing X-JSON it should be
placed inside the response object? e.g.&nbsp; "xhr.json" similar to
"xhr.responseText"<br>
<br>
Thoughts?<br>
<br>
Colin<br>
<br>
----code examples-----<br>
Hypothetical JS using my suggestion:<br>
onComplete: function(xhr,json){<br>
&nbsp;&nbsp;&nbsp; console.debug(xhr.responseText); //the
responseText<br>
&nbsp;&nbsp;&nbsp; console.debug(xhr.json); //the evaluated responseText
(if
"Content-type: application/x-json")<br>
&nbsp;&nbsp;&nbsp; console.debug(json); //the X-JSON evaluated
header<br>
&nbsp;&nbsp;&nbsp; if(json &amp;&amp; json.error){ alert(json.error);
return; }<br>
&nbsp;&nbsp;&nbsp; if(json &amp;&amp; json.login){ showLogin(); return;
}<br>
&nbsp;&nbsp;&nbsp; //do something with xhr.json<br>
}<br>
<br>
Hypothetically on the server-side (PHP):<br>
ob_start();<br>
$status = Array();<br>
$json = Array();<br>
if(!$loggedIn){<br>
&nbsp;&nbsp;&nbsp; $status['login'] = 'true';<br>
&nbsp;&nbsp;&nbsp; header('X-JSON: ('.json_encode($status).')');<br>
&nbsp;&nbsp;&nbsp; return;<br>
}<br>
<br>
if( /*handling request using JSON */ ){<br>
&nbsp;&nbsp;&nbsp; if(/*error*/){ $status['error'] = 'Error message!';
}<br>
&nbsp;&nbsp;&nbsp; else{ $json['data'] = Array(/* data here */); }<br>
}else if( /*handling request with HTML */){<br>
&nbsp;&nbsp;&nbsp; if(/*error*/){ $status['error'] = 'Error message!';
}<br>
&nbsp;&nbsp;&nbsp; else{ print '&lt;b&gt;HTML! Yay!&lt;/b&gt;'; }<br>
}<br>
$content = ob_get_clean();<br>
<br>
if($status){<br>
&nbsp;&nbsp;&nbsp; header('X-JSON: ('.json_encode($status).')');<br>
}<br>
if($json){<br>
&nbsp;&nbsp;&nbsp; header('Content-type: application/x-json');<br>
&nbsp;&nbsp;&nbsp; print '('.json_encode($json).')';<br>
}else{<br>
&nbsp;&nbsp;&nbsp; print $content;<br>
}<br>
<br>
Alexander Presber wrote:
<blockquote cite="mid:124E46EC-469D-4A9E-990B-CD7A9A1312E9@weisshuhn.de"
 type="cite">
  <pre wrap="">Am 22.01.2007 um 13:46 schrieb Dave Crane:

  </pre>
  <blockquote type="cite">
    <pre wrap="">On Saturday 20 January 2007 15:22, Kjell Bublitz wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">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)

      </pre>
    </blockquote>
    <pre wrap="">My reading of the X-JSON header was that it's useful in
cases where
you want
to pass some secondary data back with a response. The practice of
'piggy-backing' data in this way isn't to everybody's taste, but it
can be a
useful way of avoiding extra traffic.

Rails &amp; Prototype both have a strong bent towards delivering
fragments of HTML
rather than data in the response. In this case, If you're sending back
content, I don't see how to easily embed secondary data inside the
main
response body, other than stuffing it into a hidden DIV, which
loses several
hundred points for elegance. Sure, if you're delivering data
anyway, X-JSON
isn't particularly useful.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Just want to support that opinion. We are using the X-JSON header
exactly for that.

Alex

  </pre>
  <blockquote type="cite">
    <pre wrap="">On Monday 22 January 2007 12:42, Mislav wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">Will be done:
<a class="moz-txt-link-freetext"
href="http://dev.rubyonrails.org/ticket/7295">http://dev...
      </pre>
    </blockquote>
    <pre wrap="">Just saw this come in on the list - sounds like a good
suggestion
to me.



Just my $0.02

Dave
--
----------------------
Author
Ajax in Action <a class="moz-txt-link-freetext"
href="http://manning.com/crane">http://manning.com/crane...
Ajax in Practice <a class="moz-txt-link-freetext"
href="http://manning.com/crane2">http://manning.com/cran...
Prototype &amp; Scriptaculous Quickly <a class="moz-txt-link-freetext"
href="http://manning.com/crane3">http://manning.com/cran...

    </pre>
  </blockquote>
  <pre wrap=""><!---->



  </pre>
</blockquote>
<br>
--~--~---------~--~----~------------~-------~--~----~<br>
You received this message because you are subscribed to the Google
Groups &quot;Ruby on Rails: Spinoffs&quot; group. <br> To post to this
group, send email to rubyonrails-spinoffs@googlegroups.com <br> To
unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe@googlegroups.com <br> For more options,
visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en <br>
-~----------~----~----~----~------~----~------~--~---<br>
</body>
</html>

<br>
8f93a872e399bc1353cc8d4e791d5401?d=identicon&s=25 Mislav MarohniÄ? (mislav)
on 2007-01-22 18:29
(Received via mailing list)
On 1/22/07, Colin Mollenhour <eliteii92g@mollenhour.com> wrote:
>
>  This change, while I think is a good idea in general, will be somewhat
> difficult to make use of if the new JSON object replaces the old JSON
> object.
>

You have a point there. I didn't think people would care, but you have
convinced me they could.

Your idea of writing to the "json" property of the xhr object is not
bad.
Alternatively, there could be a "getJson()" method that lazily evaluates
"responseText".
A5c2cf0ecee0dc7b1663856892ade523?d=identicon&s=25 Dave Crane (Guest)
on 2007-01-22 18:41
(Received via mailing list)
On Monday 22 January 2007 15:56, Ed C. wrote:
> This seems like almost a duplication of effort -- we already have access to
> the HTTP status codes, which could (should?) be used to determine success
> (example, 200 = OK, 500 = Error). The content body includes the results or
> error message(s).
>
HTTP 500 is generally used to signal an application error somewhere in
the
system (the database is down, you tried to divide by zero, and so on).
Similarly, other status codes relate to the status of the attempted HTTP
request and response (e.g. 401 = your request requires authentication).

This is a different thing from an application error or status code e.g.
'the
object you are trying to update is a stale copy'. X-JSON can also be
used for
status/update data such as 'you have three outstanding cases, here are
their
names and ids', to automatically refresh a list in the background, every
time
you request or update anything in your app (in which case the request
body is
busy reporting something else).

Mislav - yes, X-JSON is a hack, and an acceptable one IMO, with a good
pedigree. As you point out, multipart MIME type responses are a hack on
top
of HTTP - so are CGI parameters, and sessions, if you look at what HTTP
was
originally designed to do.

Dave

--
----------------------
Author
Ajax in Action http://manning.com/crane
Ajax in Practice http://manning.com/crane2
Prototype & Scriptaculous Quickly http://manning.com/crane3
Eea3feaacbe44706164289d068d94828?d=identicon&s=25 Peter Michaux (Guest)
on 2007-01-22 18:57
(Received via mailing list)
On 1/19/07, Kjell Bublitz <m3nt0r.de@gmail.com> wrote:
>
> Thats why i chose "text/x-json" over "application/x-json". It is
> readable text, after all

I puzzled over the choice of "application" first but can think of a
couple reasons "application" could be more natural.

JSON is expressed in JavaScript. JavaScript is distributed as text not
is some unreadable compiled binary. If it could be distributed in a
small compiled form it surely would and so "application" would be more
clearly appropriate.

JSON is expressed in JavaScript. JavaScript is a programming language
that describes behavior aspect of a web page. Behavior is in the
application realm.

Peter
--
JavaScript for Rails: http://forkjavascript.org
F72d844cd647e3a0b36255724bfd9c9f?d=identicon&s=25 Kjell Bublitz (m3nt0r)
on 2007-01-22 19:28
(Received via mailing list)
If i query a XML service, i get a XML response (text/xml) - with error
or data
If i query a JSON service, i get a JSON response (application/json) -
with error or data

Is there something to disagree?

Only because there is a hack which allows transport of HTML (or
whatever) along with a pure dataformat, i don't see why that should be
a keeper. I personally create such fragments from JSON data, or modify
the application behaviour. There is no text/html involved in that
action and i belief that this is the whole purpose of JSON. If my
application uses pre-generated HTML aside from JSON -in a row-, i
should ask myself why i use JSON at all. Just for a 'yay or nay'?? I
don't think so..

But.. it's a matter of application design after all. Generally: mixing
mime is bad.

- Kjell

On 1/22/07, Dave Crane <dave@cranefamily.force9.co.uk> wrote:
> request and response (e.g. 401 = your request requires authentication).
> of HTTP - so are CGI parameters, and sessions, if you look at what HTTP was
>
> >
>


--
Kjell
-- www.m3nt0r.de
A90ce1c25149f0b37c313cd68f82c790?d=identicon&s=25 William F. Attwood (Guest)
on 2007-01-22 19:39
(Received via mailing list)
Good Day -

   While I read through these comments, I decided for the first time in
awhile to throw in my own two cents.

   JSON stands for: JavaScript Object Notation.  If we take the first
word in that title: JavaScript, we get our answer.  JSON is, through
it's basis, JavaScript -- so set the MIME type as so; application.

   Just because you can read text and understand what it means and what
it does is not a valid method to describe the data as simple text.  I
can read binary code (albeit slowly), but that does not mean it is text.

--Will




----- Original Message -----
From: "Peter Michaux" <petermichaux@gmail.com>
To: rubyonrails-spinoffs@googlegroups.com
Sent: Monday, January 22, 2007 10:56:30 AM (GMT-0700) US/Mountain
Subject: [Rails-spinoffs] Re: About X-JSON header and evil things... ;)


On 1/19/07, Kjell Bublitz <m3nt0r.de@gmail.com> wrote:
>
> Thats why i chose "text/x-json" over "application/x-json". It is
> readable text, after all

I puzzled over the choice of "application" first but can think of a
couple reasons "application" could be more natural.

JSON is expressed in JavaScript. JavaScript is distributed as text not
is some unreadable compiled binary. If it could be distributed in a
small compiled form it surely would and so "application" would be more
clearly appropriate.

JSON is expressed in JavaScript. JavaScript is a programming language
that describes behavior aspect of a web page. Behavior is in the
application realm.

Peter
--
JavaScript for Rails: http://forkjavascript.org
8f93a872e399bc1353cc8d4e791d5401?d=identicon&s=25 Mislav MarohniÄ? (mislav)
on 2007-01-22 20:07
(Received via mailing list)
On 1/22/07, Kjell Bublitz <m3nt0r.de@gmail.com> wrote:
>
>
> But.. it's a matter of application design after all. Generally: mixing
> mime is bad.


Ever uploaded a file through a browser, or received a HTML/txt e-mail?
I'm
sorry to break it to you like this, but you mixed mime when you did :)

William F.: we got over the MIME-type discussion. "application/json" is
here
to stay, "text/x-json" is invalid.

Kjell, if I understand correctly, you're suggesting to drop X-JSON
header
feature in favor of JSON in body?

If we did that, it would make a lot of developers sad :(

My reasons to keep it:

   1. it's a simple hack;
   2. it's easy to do;
   3. it's not bloat to the framework;
   4. HTML, text or even XML with a side-dish of JSON is yummy.

--
Mislav
4dae3b057d62f103f56d2c5d58007a08?d=identicon&s=25 Ryan Gahl (Guest)
on 2007-01-22 20:16
(Received via mailing list)
Are they necessarily mutually exclusive? Can X-JSON not stay for those
who
like it, and support for a _configurable_OR_standard_ content type be
added?
This seems like something that could be configurable at the application,
page, or request level under various conditions or developer preference.

On 1/22/07, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:
>
>    1. it's a simple hack;
>    2. it's easy to do;
>    3. it's not bloat to the framework;
>    4. HTML, text or even XML with a side-dish of JSON is yummy.
>
> --
> Mislav
>
> >
>


--
Ryan Gahl
Application Development Consultant
Athena Group, Inc.
Inquire: 1-920-955-1457
Blog: http://www.someElement.com
Efaeeca3f65a4f95897dd1f20f2a7909?d=identicon&s=25 Tom Gregory (Guest)
on 2007-01-23 22:12
(Received via mailing list)
Pardon my ignorance, but huh?  I thought this *was* the group for
Prototype/Script.aculo.us requests.  Is there someplace else I should
be looking?

Or did I misunderstand--do you see this as a RoR change request, and
were suggesting it go there?


TAG
F72d844cd647e3a0b36255724bfd9c9f?d=identicon&s=25 Kjell Bublitz (m3nt0r)
on 2007-01-23 22:16
(Received via mailing list)
Probably misunderstood. This discussion is about a change/enhancement
in the prototype.js core.

You are in the group for Prototype/Script.aculo.us and RoR.
So.. this is the right place for your requests.

On 1/23/07, Tom Gregory <tomg@byu.net> wrote:
>
> > Mislav
>
>
> >
>


--
Kjell
-- www.m3nt0r.de
F72d844cd647e3a0b36255724bfd9c9f?d=identicon&s=25 Kjell Bublitz (m3nt0r)
on 2007-01-23 22:20
(Received via mailing list)
Good call. I am not all against the support of X-JSON. I just would
like to see my suggestion as being added one way or another cause i
thought this was missing.

I personally like the object extension which was suggested earlier.
Maybe something like responseJSON ...


On 1/22/07, Ryan Gahl <ryan.gahl@gmail.com> wrote:
> > > But.. it's a matter of application design after all. Generally: mixing
> >
> >
> Athena Group, Inc.
> Inquire: 1-920-955-1457
> Blog: http://www.someElement.com
>
>  >
>


--
Kjell
-- www.m3nt0r.de
Efaeeca3f65a4f95897dd1f20f2a7909?d=identicon&s=25 Tom Gregory (Guest)
on 2007-01-23 22:27
(Received via mailing list)
My bad.  I found it list here: http://prototypejs.org/discuss

Full group address: http://groups-beta.google.com/group/prototype-core

I missed the announcement as I've not heavily perused the new
prototype site.  Most of my interaction with Prototype/S.a.us comes
from this list.


TAG
E46f53a17f78d9407e7bf2999d38ea67?d=identicon&s=25 Martin Bialasinski (Guest)
on 2007-01-23 22:34
(Received via mailing list)
On 1/23/07, Tom Gregory <tomg@byu.net> wrote:
> My bad.  I found it list here: http://prototypejs.org/discuss
>
> Full group address: http://groups-beta.google.com/group/prototype-core
>
> Most of my interaction with Prototype/S.a.us comes from this list.

I don't quite see the reason for the second list. Is there any problem
using this list for discussing changes and future developement?
E46f53a17f78d9407e7bf2999d38ea67?d=identicon&s=25 Martin Bialasinski (Guest)
on 2007-01-23 22:43
(Received via mailing list)
On 1/23/07, Kjell Bublitz <m3nt0r.de@gmail.com> wrote:
> Good call. I am not all against the support of X-JSON. I just would
> like to see my suggestion as being added one way or another cause i
> thought this was missing.

There is another thing that might speak towards application/json.
There is this fracking Norton Personal Firewall application that acts
as a web proxy and that injects its own javascript code into pages
fetched.

When I return JSON data in the return body, I set the content type to
application/json,  as sending the data as text/html might seduce
Norton to mess it up. Although I can't test if it is really necessary
(I have no spare machine to infect with Norton). Did someone test a
similar setup?

Bye,
  Martin
5bf4a96e583a502a810ad66fc343a60f?d=identicon&s=25 Christophe Porteneuve (Guest)
on 2007-01-23 22:44
(Received via mailing list)
Martin Bialasinski a écrit :
> I don't quite see the reason for the second list. Is there any problem
> using this list for discussing changes and future developement?

- Spinoffs is for assistance with Prototype and script.aculo.us both.
It's mostly a helpdesk.

- Prototype-Core is the list for discussion on the evolution of
Prototype, at all levels: global architecture, individual features, etc.

--
Christophe Porteneuve a.k.a. TDD
"[They] did not know it was impossible, so they did it." --Mark Twain
Email: tdd@tddsworld.com
E46f53a17f78d9407e7bf2999d38ea67?d=identicon&s=25 Martin Bialasinski (Guest)
on 2007-01-23 23:04
(Received via mailing list)
On 1/23/07, Christophe Porteneuve <tdd@tddsworld.com> wrote:

> - Spinoffs is for assistance with Prototype and script.aculo.us both.
> It's mostly a helpdesk.
>
> - Prototype-Core is the list for discussion on the evolution of
> Prototype, at all levels: global architecture, individual features, etc.

These are the topics, but I was wondering why it was felt necessary to
divide the group.

Changes are mostly because of users' needs and uses. When the needs
and uses manifest themselves on the first list, and the discussion
about how and what to change happens on the second list, then I fear
the code created might not address the problems in the best way
because of missing input from divers users. Kind of an artificial
barrier between the two groups.

Time will tell, I wish you best luck.

I just don't feel the necessity to divide the two topics. They
pollinate each other, the message count is not overwhelming and the
different topics are easily manageable in any decent reader.
8f93a872e399bc1353cc8d4e791d5401?d=identicon&s=25 Mislav MarohniÄ? (mislav)
on 2007-01-23 23:28
(Received via mailing list)
On 1/23/07, Martin Bialasinski <klingeling@gmail.com> wrote:
>
>
> These are the topics, but I was wondering why it was felt necessary to
> divide the group.


Signal vs. noise ratio. If you didn't notice, the Prototype core team
(except for Thomas) didn't participate much on this list. (TDD did, but
he
was not core back then.) I tried to catch up every now and then, but
there
was too much noise so I'm not subscribed to it anymore.

This is the place for practical questions where the community helps the
community, and where we drop by every now and then to check what's new,
what
are the common topics, etc.

We needed a place where there would be less noise so we could
concentrate on
ideas for improvement, new features and similar things. Hence
prototype-core
group.

Rails did this also, and it turned out to be a great idea.

If anyone else feels he would add to the X-JSON discussion, go right
ahead -
no need to move the discussion to core group now. But, everything has
been
pretty much said by now, and we're not dropping the header feature.

-M
04c69f3c78abbc2f8e0c0e72428312e0?d=identicon&s=25 mryhanen (Guest)
on 2007-01-24 17:23
(Received via mailing list)
Glad I found this discussion and that auto evaluation of the response
body depending on Media Type is in the works since it's a good thing
and the X-JSON header does generate some confusion.

One suggestion though: Shouldn't the json text be verified before
evaluted, as described in the application/json RFC
(http://www.ietf.org/rfc/rfc4627.txt):

var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
             text.replace(/"(\\.|[^"\\])*"/g, ''))) && eval('(' + text
+ ')');



Matti Ryhänen
E813e9cc70159e103a64a5237c0d3ee2?d=identicon&s=25 Thomas Fuchs (Guest)
on 2007-01-24 19:05
(Received via mailing list)
As you can only generate yourself (as Ajax is not cross-domain),
that's probably not necessary, but it wouldn't hurt either.
One thing is that stuff like this can introduce very strange bugs
that can take very long to debug ("whoops, where's my JSON gone?").

Think about it, how about a Object.fromJSON(json) function for this?

Best,
Thomas

Am 24.01.2007 um 17:17 schrieb mryhanen:
E813e9cc70159e103a64a5237c0d3ee2?d=identicon&s=25 Thomas Fuchs (Guest)
on 2007-01-24 20:03
(Received via mailing list)
I meant, "Thinking about it, ...".

Am 24.01.2007 um 18:44 schrieb Thomas Fuchs:
6d980c09cc3fd1913deb45d8c4b8d1a3?d=identicon&s=25 tobie (Guest)
on 2007-01-25 04:00
(Received via mailing list)
I've taken a go a it. see preliminary details here
http://dev.rubyonrails.org/ticket/7295 (last comments).

I'll post a patch tomorrow.

Best,

Tobie
6d980c09cc3fd1913deb45d8c4b8d1a3?d=identicon&s=25 tobie (Guest)
on 2007-01-25 05:16
(Received via mailing list)
Patch: http://dev.rubyonrails.org/ticket/7295

and live tests:
http://sandbox.tobielangel.com/prototype/rev_6028/...
http://sandbox.tobielangel.com/prototype/rev_6028/...

I'm having issues in IE (don't know if its the actual code or the
testing that is causing the problem).

The JSON sanitazing regex is taken from http://www.json.org/json.js
with permission from Douglas Crockford.

Would like to get as much feedback as possible so we can make it really
bulletproof.

Thanks,

Tobie
04c69f3c78abbc2f8e0c0e72428312e0?d=identicon&s=25 Matti Ryhanen (Guest)
on 2007-01-25 13:24
(Received via mailing list)
I think that the IE-issues are there regardless of your patch. At least
the
tests are failing for me without it too.

On IE7 there will be issues with the tests when using the XHR on a local
file: URL, like the relative ones in the ajax.html tests, because the
new
native IE7 XHR-object will not allow request to local url:s.

The tests will run if the ActiveX XHR-object is loaded for all IE
versions,
but I don't think this is a good solution since there seem to be yet
other
issues with the ActiveX-object and IE7, and the Native IE7-object should
be
used.


The test for Ajax.Responders will fail even using the ActiveX object,
and
from what I can tell, the two failed test there happen because IE and
firefox seem to fire readystatechanges for readyState 4 at different
times.
I'm not sure this is much of an issue though, and maybe the tests should
be
changed to reflect this?

Matti Ryhänen
8f93a872e399bc1353cc8d4e791d5401?d=identicon&s=25 Mislav MarohniÄ? (mislav)
on 2007-01-25 14:43
(Received via mailing list)
Ajax.Responders test failing is a know issue due to behavior of the
ActiveX
XHR object.

All these (testing) issues will be addressed when Ajax is finally tested
against a proper Webrick backend. That means no more testing Ajax
without
Ruby or over local "file:" scheme, but hey -- you couldn't even
"compile"
the framework without Ruby, either.

-M
0db9fec6cfc257aa9daa75f20ba1e625?d=identicon&s=25 Colin Mollenhour (Guest)
on 2007-01-25 17:03
(Received via mailing list)
Is the sanitize step necessary?  What would the performance hit be like
on a large response, and is the added complexity worth the trouble
considering all responses come from a controlled environment? You don't
sanitize HTML or XML responses, I say just use eval inside a try/catch.

Thanks,
Colin
9f68b603a93343463b949b2ab140fbe0?d=identicon&s=25 Michael Peters (Guest)
on 2007-01-25 17:08
(Received via mailing list)
Colin Mollenhour wrote:
> Is the sanitize step necessary?  What would the performance hit be like
> on a large response, and is the added complexity worth the trouble
> considering all responses come from a controlled environment? You don't
> sanitize HTML or XML responses, I say just use eval inside a try/catch.

I agree. And in case the data can't be trusted then provide an optional
parameter signifying that it needs to be cleaned first.

--
Michael Peters
Developer
Plus Three, LP
6d980c09cc3fd1913deb45d8c4b8d1a3?d=identicon&s=25 tobie (Guest)
on 2007-01-25 18:18
(Received via mailing list)
Colin, Michael, sanitizeJSON is an option and is off by default.

If is data created by a user, you better sanitize it.

The performance hit isn't that bad really.

Tobie

On Jan 25, 11:02 am, Colin Mollenhour <eliteii...@mollenhour.com>
6d980c09cc3fd1913deb45d8c4b8d1a3?d=identicon&s=25 tobie (Guest)
on 2007-01-25 19:25
(Received via mailing list)
Sorry for the sloppy typing. I obviously meant "If IT is data created
by a user, you better sanitize it. "
E46f53a17f78d9407e7bf2999d38ea67?d=identicon&s=25 Martin Bialasinski (Guest)
on 2007-01-25 20:57
(Received via mailing list)
On 1/25/07, tobie <tobie.langel@gmail.com> wrote:
>
> Colin, Michael, sanitizeJSON is an option and is off by default.

Regarding your patch: Shouldn't the X-JSON processing also use
evalJSON() ?

And WRT to options.sanitizeJSON, how about a AJAX.sanitizeJSON global
option for the default behaviour? Then a developer he want to sanitize
every response can set this to true once and he does not have to
specifiy this option on every call.

string.evalJSON() returns
 Object  if everything is OK
 null if eval failed
 undefined if sanitize was requested and failed

Shouldn't the last case also return null?

On the Ajax object, a seed for a discussion on how it should behave:

transport.responseJSON is always initialized with "undefined". Users
can compare with undefined to see if there was JSON data in the
response at all.

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?

I say yes. It should not matter what way (header / body) was used to
transfer the data.

> If is data created by a user, you better sanitize it.

Sure, but the server script creating the JSON response should create a
valid JSON representation of the user supplied data. If it cannot
assure this, then this is the component to fix first.

Bye,
  Martin
E46f53a17f78d9407e7bf2999d38ea67?d=identicon&s=25 Martin Bialasinski (Guest)
on 2007-01-25 21:11
(Received via mailing list)
On 1/25/07, Martin Bialasinski <klingeling@gmail.com> wrote:

> Regarding your patch: Shouldn't the X-JSON processing also use evalJSON() ?

Oops. It does, of cause.
6d980c09cc3fd1913deb45d8c4b8d1a3?d=identicon&s=25 tobie (Guest)
on 2007-01-25 21:46
(Received via mailing list)
Hi, thanks for the feedback.

I'm working on a better handling of exceptions. Will post a patch asap.

Regarding x-json, I think we should leave it as it is for consitency
and backwards compatibility. It should also still be available if the
mime-type is set to application/json.

I had thaught about a global AJAX.sanitizeJSON option. It certainly
something we could implement at some point, but there are some
potential issues with that (especially if you rely on some third party
libs also using Prototype). Your best option for such cases is to
create a var holding your hash of options and reference it each time.

Thanks for the extended comment.

Cheers,

Tobie
F72d844cd647e3a0b36255724bfd9c9f?d=identicon&s=25 Kjell Bublitz (m3nt0r)
on 2007-01-25 21:53
(Received via mailing list)
I think sanitizeJSON should be optional.. {sanitize: true}

my 2 cents.

On 1/25/07, tobie <tobie.langel@gmail.com> wrote:
> something we could implement at some point, but there are some
>
> >
>


--
Kjell
-- www.m3nt0r.de
6d980c09cc3fd1913deb45d8c4b8d1a3?d=identicon&s=25 tobie (Guest)
on 2007-01-25 22:13
(Received via mailing list)
It is, see above
0db9fec6cfc257aa9daa75f20ba1e625?d=identicon&s=25 Colin Mollenhour (Guest)
on 2007-01-25 22:51
(Received via mailing list)
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
F72d844cd647e3a0b36255724bfd9c9f?d=identicon&s=25 Kjell Bublitz (m3nt0r)
on 2007-01-25 23:09
(Received via mailing list)
responseText
responseXML
responseJSON

so self-evident ^^

my vote for responseJSON :)

On 1/25/07, Colin Mollenhour <eliteii92g@mollenhour.com> wrote:
> Cheers,
> >
> >
> > the X-JSON header.
> > If If content-type is application/json, should it gets its value from
> > from the responseText?
> >
> >
>
>
> >
>


--
Kjell
-- www.m3nt0r.de
E46f53a17f78d9407e7bf2999d38ea67?d=identicon&s=25 Martin Bialasinski (Guest)
on 2007-01-25 23:13
(Received via mailing list)
On 1/25/07, tobie <tobie.langel@gmail.com> wrote:

> I had thaught about a global AJAX.sanitizeJSON option. It certainly
> something we could implement at some point, but there are some
> potential issues with that (especially if you rely on some third party
> libs also using Prototype).

That would be only a problem, if the third party module depends on
evalJSON() to not only return an object, but to also execute some
commands contained in the data, which makes the data not a JSON
structure in the first place and it is then an error to call evalJSON.

Bye,
  Martin
6d980c09cc3fd1913deb45d8c4b8d1a3?d=identicon&s=25 tobie (Guest)
on 2007-01-26 05:16
(Received via mailing list)
> > I had thaught about a global AJAX.sanitizeJSON option. It certainly
> > something we could implement at some point, but there are some
> > potential issues with that (especially if you rely on some third party
> > libs also using Prototype).That would be only a problem, if the third party module 
depends on
> evalJSON() to not only return an object, but to also execute some
> commands contained in the data, which makes the data not a JSON
> structure in the first place and it is then an error to call evalJSON.

Hi Martin,

You're right. However, the only consistent way to do this in my
opinion, is to have ALL defaults options available as a property of the
Ajax object (Something similar to what script.aculo.us implemented for
Effect), like so:

Ajax.DEFAULT_OPTIONS  = {
  asynchronous: true,
  sanitizeJSON: false,
  etc...
}

As this might have further implications, I believe it should dealt as a
separate issue.

But I agree with you, it would be a great feature.

Best,

Tobie
6d980c09cc3fd1913deb45d8c4b8d1a3?d=identicon&s=25 tobie (Guest)
on 2007-01-26 11:27
(Received via mailing list)
E813e9cc70159e103a64a5237c0d3ee2?d=identicon&s=25 Thomas Fuchs (Guest)
on 2007-01-26 12:05
(Received via mailing list)
Tobie:

See http://dev.rubyonrails.org/changeset/5986 for an example of using
the built-in HTTP server (WEBrick) test environment for
testing stuff like this.

You can add:

@server.mount_proc("/JSON") do |req, res|  ...

Then just spit back stuff, depending on params.

Best,
Thomas


Am 26.01.2007 um 11:27 schrieb tobie:

>
>
> >

--
Thomas Fuchs
wollzelle

http://www.wollzelle.com

questentier on AIM
madrobby on irc.freenode.net

http://www.fluxiom.com :: online digital asset management
http://script.aculo.us :: Web 2.0 JavaScript
http://mir.aculo.us :: Where no web developer has gone before
6d980c09cc3fd1913deb45d8c4b8d1a3?d=identicon&s=25 tobie (Guest)
on 2007-02-12 06:42
(Received via mailing list)
Hi All,

Thanks for your patience. I've encountered annoying issues which I
hadn't foreseen, mainly that IE6 doesn't allow modifying or adding
properties to the response object.

I've dealt with that by cloning the transport when needed... and I'd
like as much input as possible on this proposition as I'm a bit
worried about the possible side effects.

You can find the patch here: http://dev.rubyonrails.org/ticket/7295

To summarize, this patch adds:
- automatic evaluation of JSON if the mime-type is set to application/
json.
- evaluation of JSON if the evalJSON option is set to true (regardless
of the mime-type).
- the possibility to sanitize your JSON by setting the sanitizeJSON
option to true (to guard against user-entered data for example).
- the evaluated JSON comes nicely wrapped up as the responseJSON
property of the transport object.
- the x-json header is kept as is (except it also gets sanitized if
the sanitizeJSON option is used).
- there's an added String.prototype.evalJSON method
- automatic Opera testing has been added to rake (would need a bit of
polishing on windows and Linux - if anybody volunteers).
- all the tests you need (they will only run if launched from rake -
you have been warned!)
- full support in Safari, Firefox, Opera 9, IE6 & 7

Thanks for your input and best regards,

Tobie
6d980c09cc3fd1913deb45d8c4b8d1a3?d=identicon&s=25 tobie (Guest)
on 2007-02-12 06:47
(Received via mailing list)
oh! and I completely forgot to mention the patch for JSON encoding
(which doesn't mess with Object.prototype):
http://dev.rubyonrails.org/ticket/7427
0db9fec6cfc257aa9daa75f20ba1e625?d=identicon&s=25 Colin Mollenhour (Guest)
on 2007-02-12 19:02
(Received via mailing list)
Great work, I'm glad you were able to get it working despite IE6's
limitations. Looking forward to checking out that patch and giving it a
try.

Thanks,
Colin
0db9fec6cfc257aa9daa75f20ba1e625?d=identicon&s=25 Colin Mollenhour (Guest)
on 2007-02-20 09:31
(Received via mailing list)
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I just thought of a simple solution that would not require messing with
the transport object. I posted a comment on Tobie's ticket
(<a class="moz-txt-link-freetext"
href="http://dev.rubyonrails.org/ticket/7295#comment:15"...)
to the same effect,
but I'll post it here for others to see as well.<br>
<br>
Why
not eval the X-JSON header, then, if Content-type is
'application/json', eval it as well and <strong>Object.extend</strong>
the X-JSON eval'ed response! This is more similar to Tobie's original
suggestion, only rather than replacing it you would extend it.
<div class="comment">
<p>This solution has the following advantages:
</p>
<ul>
  <li>Backwards compatibility with X-JSON response being the second
argument to onXXX
  </li>
  <li>Won't break cases where bind was used to add additional arguments
to onXXX
  </li>
  <li>Doesn't require writing to the transport object (or cloning)
  </li>
  <li>Keeps the API simple by using one object argument to handle both
cases
  </li>
  <li>Users can migrate their code to Content-type without changing the
JS code
  </li>
  <li>No data is lost <i>unless</i> properties in the Content-type
object override properties in the X-JSON object. This is the only
danger, but I think it is acceptable.
  </li>
</ul>
<p>So a response like:<br>
---------------<br>
X-JSON: ({status: "go"})<br>
Content-type: application/json<br>
</p>
<p>({data: ['one','two','ten']})<br>
</p>
<p>----------------<br>
</p>
<p>Could be used like so:<br>
----------------</p>
<p>Ajax.Responders.register({<br>
&nbsp;&nbsp;&nbsp; onSuccess: function(xhr,json){<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if(json.status &amp;&amp;
json.status != 'go'){
alert('Error!'); }<br>
&nbsp;&nbsp;&nbsp; }<br>
});<br>
new Ajax.Request(page,{<br>
&nbsp;&nbsp;&nbsp; onSuccess: function(xhr,json){<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
$('count').update($A(json.data).map(function(item){ return
'&lt;li&gt;'+item.camelize()+'&lt;/li&gt;'; }).join(''));<br>
&nbsp;&nbsp;&nbsp; }<br>
});<br>
</p>
<p>Thoughts? I personally prefer this over my original suggestion which
was to add a new property to the transport, mainly for simplicity.<br>
</p>
<p>Colin
</p>
</div>
<br>
--~--~---------~--~----~------------~-------~--~----~<br>
You received this message because you are subscribed to the Google
Groups &quot;Ruby on Rails: Spinoffs&quot; group. <br> To post to this
group, send email to rubyonrails-spinoffs@googlegroups.com <br> To
unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe@googlegroups.com <br> For more options,
visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en <br>
-~----------~----~----~----~------~----~------~--~---<br>
</body>
</html>

<br>
6d980c09cc3fd1913deb45d8c4b8d1a3?d=identicon&s=25 tobie (Guest)
on 2007-02-21 06:07
(Received via mailing list)
There you go:

http://dev.rubyonrails.org/ticket/7295

drops the ugly cloning in favor of a brand new Ajax.Response object.

Not ready for prime yet... as we still have to discuss how much we
want it to smoothen out browser discrepancies.

Comments welcomed.

NOTE: can only be tested through rake.

I've added Opera and WebKit to the lot.

This should probably not go into core like this as these browsers are
not officially supported.
0db9fec6cfc257aa9daa75f20ba1e625?d=identicon&s=25 Colin Mollenhour (Guest)
on 2007-02-21 08:03
(Received via mailing list)
Please explain the necessity of a wrapper for the httprequest object.. I
see it simply as more overhead and extraneous bulk. I definitely like
the string.prototype.evalJSON and the options.sanitizeJSON, but rather
than the Ajax.Response wrapper, consider this simple patch to the
current system:

+    var contentType = this.getHeader('Content-type');
    if (state == 'Complete') {
      try {
+        if(contentType &&
contentType.strip().startsWith('application/json'))
+          Object.extend(json || {},
transport.responseText.evalJSON(options.sanitizeJSON) || {});
        this._complete = true;

Will these three lines not accomplish what this patch is all about,
making automatic JSON evaluation more usable? Keep it simple.

Thanks,
Colin
0db9fec6cfc257aa9daa75f20ba1e625?d=identicon&s=25 Colin Mollenhour (Guest)
on 2007-02-21 08:20
(Received via mailing list)
Well, that code has a problem or two, but you get the idea..
E5820d604f89c44dceacbc10ccdf0dcd?d=identicon&s=25 Yuri de Wit (Guest)
on 2007-03-01 02:55
Related but unrelated, I have been having problems receiving X-JSON
header in Safari. It works fine in IE and in Firefox, i.e. the X-JSON
header contains the json state returned by the server, but in Safari it
is null.

Any ideas? Pointers?

thanks
F72d844cd647e3a0b36255724bfd9c9f?d=identicon&s=25 Kjell Bublitz (m3nt0r)
on 2007-09-25 22:39
(Received via mailing list)
That group you linked is for prototype core discussions, yes.. but not
for RoR and S.a.us

The core group is new, so this discussion was initially created here.
As being requested by Mislav, future discussions of such core specific
topics will be taken there.

If you have question regarding RoR/S.a.us go ahead and create a topic
or search online if your question has already been answered in this
group.


PS: Please don't push this topic anymore.
If you have further questions create a new topic.


On 1/23/07, Tom Gregory <tomg@byu.net> wrote:
> TAG
> >
> >>
> >> --
> >> Mislav
> >
>
>
> >
>


--
Kjell
-- www.m3nt0r.de
This topic is locked and can not be replied to.