Hmm, right... then maybe DataContextTransactionEventListener - an
object itself can register on modification of its transient
properties. In "dataContextWillCommit" it can change its persistent
properties.
I think it has a bug (or a limitation) though - dataContextWillCommit
is fired too late in the commit cycle, when you can't change your
objects anymore.
This is where I'd appreciate your help - if you can take a look at
DataContext and DataContextCommitAction and make sure it fires
dataContextWillCommit before the validation, then it will be a much
more usable hook. Or maybe we can leave it alone and introduce an
extra method "dataContextWillPrepareToCommit" or something.... I
wonder how useful is the current lifecycle method (called after
validation, pk generation and finalizing the commit queries, but
before the actual INSERT/UPDATE/DELETE execution)?
Andrus
On Sep 28, 2005, at 1:16 PM, Cris Daniluk wrote:
>> So what you are suggesting is another lifecycle method. I wonder if
>> DataObjectTransactionEventListener would work in this situation?
>>
>
> This could work, but it seems to me that it takes the decision making
> power away from the object. Normally, that's a good thing, but I think
> in this case, isn't it best to let the object decide whether its
> transient properties warrant "computing" persistent fields?
>
> Maybe it can still work. I'll tinker with it a bit..
>
>
>> I had issues with DataObject events design in the past, I guess
>> mainly because a lifecycle interface was named a listener... But the
>> functionality is there and will be preserved in some form even if we
>> refactor the event.
>>
>> Andrus
>>
>>
>>
>
>
This archive was generated by hypermail 2.0.0 : Wed Sep 28 2005 - 13:30:59 EDT