I brought this up recently too.
(http://groups.google.com/group/transfer-dev/browse_thread/thread/ecc7004e953fb43e?hl=en#)
I also think null dates should end up as null dates, and that null
numerics should end up as nulls as well. But as Mark said, something
configurable that could do the same would be great.
Something else funny that happens with NULL dates is that the "NULL"
value that Transfer returns is a coldfusion.runtime.OleDateTime,
whereas non-null dates are returned as Strings. This behavior seems
inconsistent, and it threw me for a loop when I was trying to debug
why one date (NULL) serialized to Flex, and another (concrete date)
failed to serialize properly.
Jamie
On Sun, Jan 11, 2009 at 8:05 PM, Matt Quackenbush <quackfu...@gmail.com> wrote:
> Jon, thanks for the info. I've not previously noticed that, and I'm not
> really sure why I have not noticed it, seeing as that behavior has obviously
> been around for a really long time now. (I looked back at a couple of my
> old decorators and they're using configure() to default the dates, so maybe
> I just don't remember noticing it before?) Now that it has been pointed out
> though, I must admit, I'm with you and Dan on this one. If a string
> defaults to its "null" of an empty string, and a numeric value defaults to
> its "null" of 0, then yeah, a date should default to its "null" value.
>
>
> On Sun, Jan 11, 2009 at 2:23 PM, Jon Messer wrote:
>>
>> Matt it's pretty easy to reproduce, just create a nullable date property
>> on any object, then dump the memento of a new instance of that object. The
>> date will be now() not "null" (01/01/100).
>>
>> Whether or not one should have nullable attributes is another topic, but
>> the reality is there are a lot of data schemas out there that do, and to
>> assume the default behavior to be now() instead of null seems odd to me.
>>
>> So I too was annoyed by this when I first noticed it, now I just write a
>> config method for every object that has a nullable date. But doing this
>> seems like an unnecessary work around to inconsistant behavior on the part
>> of transfer.
>>
>> I think date should behave like the other data types with respect to null
>> and defaults. If I have a nullable string property it defaults to null (''),
>> a nullable number defaults to null (0), a nullable date defaults to now()
>> instead of the configured null value for a date...
>>
>> Just my opinion though, and I'm sure there are people that would naturally
>> expect a date property to default to now()...
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Before posting questions to the group please read:
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer
You received this message because you are subscribed to the Google Groups
"transfer-dev" group.
To post to this group, send email to transfer-dev@googlegroups.com
To unsubscribe from this group, send email to
transfer-dev-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/transfer-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
