No, I think that's a different beast. Renderers inherently are built to support certain types of custom data, so adding knowledge of Calendar to the date cell renderer makes sense. JSONSerializer, however, is built to support the basic JSON data types (number, string, map, list, boolean). The user wishing to serialize a Date out to JSONSerializer should have to convert the date to its millisecond representation (or better yet, just deal in milliseconds as their data model in the first place -- this is what I do in my apps). Date should get no more special treatment in JSONSerializer as any other non-JSON data type class.
-T On Wed, Sep 30, 2009 at 12:20 PM, Sandro Martini <[email protected]>wrote: > Hi Todd, > Ok, I can do the patch (but tomorrow) ... as you note in last weeks > I'm very busy at work, and I'm doing little things on Pivot, sigh ... > > Or if you have time, do it for me, no problem. > If tomorrow I didn't see the commit, I'll do it ... > > > And a last thing, similar but on JSONSerializer ... if I remember > well, in the JSON format there isn't support for Date / Timestamps, > and in out JSONSerializer we don't support Date objects (nor > Calendar). > So, what do you think on add athing like upper in this discussion, for > example converting them to a long when writing ? The problem in this > case would be when reading, so not fully solved. > Or if we could do this inside a catch, or register a user-defined > callback for these cases but we could add too much complexity here. > > What do you think ? > > > Byeeee >
