JSON Encoding

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

JSON Encoding

Douglas Crockford
The current proposal provides a default decoding of dates as ISO strings. If you
do not like that default, you can write your own toJSONString function and
attach it either to your date object or to Date.prototype. This allows you to do
anything you like. You can even generate non-JSON forms, although that is not
recommended.

One possible encoding is to emit your own date object along the lines of

     {
         "type": "Date",
         "Date": ...what you like...
     }

You can then use the hook feature of parseJSON to turn such objects into dates.

The filter function is intended to help honor protocol contracts, assuring that
JavaScript's dynamic object behavior does not lead to accidental sending of
unintended members to the server.

Reply | Threaded
Open this post in threaded view
|

Re: JSON Encoding

Bob Ippolito
On 10/20/06, Douglas Crockford <[hidden email]> wrote:
> The current proposal provides a default decoding of dates as ISO strings. If you
> do not like that default, you can write your own toJSONString function and
> attach it either to your date object or to Date.prototype. This allows you to do
> anything you like. You can even generate non-JSON forms, although that is not
> recommended.

What is the purpose of toJSONString? In my experience it's a million
times more convenient to have a "toJSON" which allows you to perform
object substitution. This also ensures that the document *must* be
valid (if it is produced at all).

> One possible encoding is to emit your own date object along the lines of
>
>      {
>          "type": "Date",
>          "Date": ...what you like...
>      }
>
> You can then use the hook feature of parseJSON to turn such objects into dates.

That sucks though because you have to generate a whole new object
graph before encoding just to make this transformation.

> The filter function is intended to help honor protocol contracts, assuring that
> JavaScript's dynamic object behavior does not lead to accidental sending of
> unintended members to the server.

Bah. If you want to explicitly select members you would implement a
toJSON on the objects that should be restricted. Filtering of a whole
object graph full of a bunch of different things with no context
borders on ridiculous.

-bob