Nope, has always been that way, I swear! :oD
Mark
On Thu, Jan 8, 2009 at 9:03 AM, Matt Quackenbush wrote:
> Thanks Mark. I realize that the docs have always used the phrase "first
> created" as well as the phrase "first initialized", but when taken in
> context with the example of setting a pr
Thanks Mark. I realize that the docs have always used the phrase "first
created" as well as the phrase "first initialized", but when taken in
context with the example of setting a property, that comes across (at least
to me) as saying "first created/initialized and ready for your consumption".
Wh
You might want to also add the corollary that object properties are not
available to the configure() function...
On Jan 7, 2009 3:45pm, Mark Mandel wrote:
>
>
> Fair point - I added a clarification to:
>
> http://docs.transfer-orm.com/wiki/Writing_Decorators.cfm
>
>
>
> Mark
>
>
>
> On Thu, Jan
Fair point - I added a clarification to:
http://docs.transfer-orm.com/wiki/Writing_Decorators.cfm
Mark
On Thu, Jan 8, 2009 at 7:14 AM, Matt Quackenbush wrote:
> Okay, thanks to Paul Marcotte for the link, it seems that I have been
> completely mistaken about the behavior of configure(). Here's
Okay, thanks to Paul Marcotte for the link, it seems that I have been
completely mistaken about the behavior of configure(). Here's a summary of
what Mark said in a different thread (
http://groups.google.com/group/transfer-dev/msg/3feee160f2147cfa?pli=1):
"So anything inside configure() is overw
Have you tried the AfterNew event? ;)
On Jan 7, 2009 1:21pm, Matt Quackenbush wrote:
> It was worth a shot, but unfortunately that did not change the behavior.
>
> I also thought "okay, I've made a ton of changes to the decorator, maybe
Transfer is just reading old stuff". However, wiping out a
It was worth a shot, but unfortunately that did not change the behavior.
I also thought "okay, I've made a ton of changes to the decorator, maybe
Transfer is just reading old stuff". However, wiping out all of the
*.transfer files still results in the same behavior.
Here's the _really_ odd part:
Hmmm... Sounds like configure() is called *before* the object is fully
populated/hydrated. Try getMemento() before getEmailAddress()... Perhaps
the getMemento() will force the object to be populated.
That would explain the getXXX() functions returning empty strings, and the
setXXX() function
To be extra, extra, extra clear, configure() *is* running. I can set
anything to the decorator itself that I want to inside of configure(),
provided that it does not come from the TO. For instance...
setConfirmAddress("transfer-ro...@transfer-orm.com");
That works perfe
Paul,
Thanks for the reply. I actually have that in another example, and it is
behaving exactly the same. I at first thought it was an issue relating to
.clone() not picking up on things I've set in the decorator, but I can dump
a non-cloned object and a cloned object and they are both identical
Matt,
Maybe try checking if the object is persisted in configure, first?
something like.
if ( getIsPersisted() ) {
setConfirmAddress(getEmailAddress());
} else {
setConfirmAddress("");
}
I'm wondering if the incorrect be
11 matches
Mail list logo
