That sounds reasonable to me. It might be a good time to make these
compatibility changes.
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...
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.
>
Anyone else care to weigh in?
Thanks
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.