We've been dealing with this same issue, and not to nitpick but I note that his question about the "why" was ignored but work-around solutions offered instead. Especially since every other value type defaults to the default null value of its type, only date fields have a non-null-like value as their default on creation.
Would a patch that adds the necessary code and a configuration file option to have dates default to their null values be considered? From what a 10-minute eval reveals it seems that it should not take more than a few lines of code to add the alternative behavior and configuration file support. Thankfully Paul points out a one time solution use Observers, which is likely the direction we will go in the short term. And Ditto with Jared, Transfer rocks very hard. Somebody tell Adobe to get Mark a "valuable-contributor" dividend going so he can write more neat stuff. -- Kevin Carter On Nov 28, 5:31 pm, "Mark Mandel" <[EMAIL PROTECTED]> wrote: > On a get the following happens: > > - creates new object > - configure() gets called > - object gets populated > - object is returned. > > So anything inside configure() is overwritten by populated data. > > Mark > > > > On Sat, Nov 29, 2008 at 9:03 AM, Paul Marcotte <[EMAIL PROTECTED]> wrote: > > Ooops, I misread your post. You could use an afterNew Observer instead. > > But I'm wondering if configure is fired even on get()? > > > ***heads to docs... > > > Paul > > > On Fri, Nov 28, 2008 at 1:59 PM, Paul Marcotte <[EMAIL PROTECTED]> wrote: > > >> Hi Jared, > > >> You can call nullifyDates() in the configure method of your decorator. > >> Transfer will fire the configure method before returning the new object. > > >> Paul > > >> On Fri, Nov 28, 2008 at 1:28 PM, Jared <[EMAIL PROTECTED]> wrote: > > >>> I read through this thread, but I still don't understand how to handle > >>> the problem where date properties of a transfer object default to Now > >>> (). I find that weird. Why don't they default to the null value for > >>> dates? Setting them to Now() is a bit like defaulting string values > >>> to "hello there" or defaulting numeric values to 17. I can't write a > >>> configure method to handle this, since I don't want to always set the > >>> date values to null (or whatever stands in for null, since CF doesn't > >>> have null (which is annoying)). I only want to do so in response to > >>> Transfer.new(). The only thing I can think of is to write a method in > >>> my decorator called nullifyDates() that goes through each date and > >>> does a setMyDatePropertyNull(). Then, whenever I do a new() for this > >>> type of object I would, on the next line, do a myObj.nullifyDates() to > >>> fix the weirdness of dates defaulting to Now(). Seems like a bit of a > >>> hack. Is that the only way? > > >>> That said, transfer is great! Long live transfer. Send Mark money. > > >> -- > >> Paul Marcotte > >> Fancy Bread - in the heart or in the head? > >>http://www.fancybread.com > > > -- > > Paul Marcotte > > Fancy Bread - in the heart or in the head? > >http://www.fancybread.com > > -- > E: [EMAIL PROTECTED] > W:www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
