I've made some improvements to the transformDates algorithm that Tibor submitted.
As you may or may not recall, this is a feature that transforms java side Dates directly into JS side Dates (instead of a JSON structure that has to be further processed into a Date.)
IMHO this should have been in json-rpc-Java from the beginning and it should be the default behavior of jabsorb, but I'm not sure if we want to make that change now at this point because it would probably break a lot of old code for people upgrading.
My changes:
a) It now works with all the java.sql Date subclasses as well. b) The ability to transform a date without a javaClass hint is now individually settable (instead of always on when JSONRpcClient.transformDates is set). New flag JSONRpcClient.transformDateWithoutHint controls this. c) On the server side, I also changed the Date serializer to support the java.sql.Time class (not sure why we missed that one before!). d) Modified the unit tests so that it's easier to test the transformDate feature. And add some new unit tests to test the sql date transformations.
I expect to make a 1.3.1 release in the near future after some more testing. If anyone wants to get the changes earlier, you can get it from SVN on the 1.3 branch.
Configuration for transformDates:
/** * If true, java Date objects are automatically unmarshalled to JS Date objects. */ JSONRpcClient.transformDates = false;
/** * If true, and JSONRpcClient.transformDates is also true, then objects that * have the single property "time" (even if no javaClass hint is defined) * will also be transformed into JS date objects. */ JSONRpcClient.transformDateWithoutHint = false;
/** * The types of java Date classes to transform into JS Dates if JSONRpcClient.transformDates is true */ JSONRpcClient.javaDateClasses = { 'java.util.Date' :true, 'java.sql.Date' :true, 'java.sql.Time' :true, 'java.sql.Timestamp':true};
Just checked out the changes, I especially like the idea of extending
JavaScript date objects with a 'javaClass' property to retain the
class hint.
Jabsorb 1.4 (currently trunk) has a redesigned JS client, so minor
code changes on the client side will be needed when migrating to 1.4.
What do you think about making transformDates and
transformDateWithoutHint true by default for 1.4?
tibor.boe...@gmail.com wrote: > Just checked out the changes, I especially like the idea of extending > JavaScript date objects with a 'javaClass' property to retain the > class hint.
> Jabsorb 1.4 (currently trunk) has a redesigned JS client, so minor > code changes on the client side will be needed when migrating to 1.4. > What do you think about making transformDates and > transformDateWithoutHint true by default for 1.4?
That sounds reasonable to me. It might be a good time to make these compatibility changes.
On Mon, Jan 5, 2009 at 9:05 PM, Michael Clark <mich...@metaparadigm.com> wrote:
> tibor.boe...@gmail.com wrote: >> Just checked out the changes, I especially like the idea of extending >> JavaScript date objects with a 'javaClass' property to retain the >> class hint.
Thanks. Yeah- I forgot to mention that one. I actually needed that feature for a project I'm working on.
>> Jabsorb 1.4 (currently trunk) has a redesigned JS client, so minor >> code changes on the client side will be needed when migrating to 1.4. >> What do you think about making transformDates and >> transformDateWithoutHint true by default for 1.4?
> That sounds reasonable to me. It might be a good time to make these > compatibility changes.
Sounds reasonable to me too, but what about the new flag, transformDateWithoutHint?
My vote is the default for that should be false, since fairly reasonable json structures might accidently get turned into dates...
> Sounds reasonable to me too, but what about the new flag,
> transformDateWithoutHint?
> My vote is the default for that should be false, since fairly
> reasonable json structures might accidently get turned into dates...
Accidental transformation might happen, when:
1. someone sets setMarshallClassHints(false) - default is true - and
uses a class with one and only property named 'time'
2. or someone creates and registers a custom serializer that
transforms a java object to JSON object that has 'time' as the only
property
I seems to me that the above cases are rather unlikely to happen
without the developer being aware of it, as both of these cases
require explicit configuration.
I would prefer and expect the same behavior with or without class
hinting enabled, hence I would consider true by default to provide a
natural behavior. (I generally test my code with class hints enabled
and disabled as well and expect the same outcome...)
Anyway, as long as the configuration options, their impact and the
default behavior is well documented (migration guide/what's new in
1.4), transformDateWithoutHint=false is a reasonable default as well.
On Thu, Jan 8, 2009 at 1:27 PM, <tibor.boe...@gmail.com> wrote:
>> Sounds reasonable to me too, but what about the new flag, >> transformDateWithoutHint?
>> My vote is the default for that should be false, since fairly >> reasonable json structures might accidently get turned into dates...
> Accidental transformation might happen, when: > 1. someone sets setMarshallClassHints(false) - default is true - and > uses a class with one and only property named 'time' > 2. or someone creates and registers a custom serializer that > transforms a java object to JSON object that has 'time' as the only > property
Another easy way is when using a JSONObject to pass add-hoc data back to the client. Something I do quite often (I'm not sure how often others do that, but I would imagine it's pretty common.).
I thought about tightening the client side check as well, by also making sure that the single 'time' property is an integer value.
> I seems to me that the above cases are rather unlikely to happen > without the developer being aware of it, as both of these cases > require explicit configuration.
It might not require explicit configuration when passing back ad-hoc JSON data like I outlined above. Yes I imagine it would be rare, but quite confusing and annoying if and when it did happen--
> I would prefer and expect the same behavior with or without class > hinting enabled, hence I would consider true by default to provide a > natural behavior. (I generally test my code with class hints enabled > and disabled as well and expect the same outcome...)
> Anyway, as long as the configuration options, their impact and the > default behavior is well documented (migration guide/what's new in > 1.4), transformDateWithoutHint=false is a reasonable default as well.
> Another easy way is when using a JSONObject to pass add-hoc data back > to the client.
I thought of passing back 'untyped' data (what you refer to as ad-hoc) via org.json classes only as a temporal solution for quick prototyping - which gets replaced for example by beans as the project moves forward... Thinking twice, however, I can well imagine situations where it is not practical to create beans for all the possible structures returned, so I agree on your point.
> I thought about tightening the client side check as well, by also > making sure that the single 'time' property is an integer value.
Yes, I totally agree there. This should have been included in my original patch. Attached is a one line mod which includes the integer check.
|
