Hi Andrus,
On 06/09/2006, at 5:46 PM, Andrus Adamchik wrote:
> Custom values set on the server during commit are not passed back
> to the client (except for the PK). It would be nice if they where,
> so that's something we may consider doing in 3.0.
Yes please.
But we're not talking about commit are we? I was talking about
init... what happens when creating a new object on the client? Do any
initial values set on the server get propagated back?
> However 'setPersistenceState' is called on the client when an
> object is created. Not sure why you are not seeing it.
I'll check again. Thanks.
>> 2) Object modifications
>>
>> DataContext has event subjects DID_COMMIT, DID_ROLLBACK,
>> WILL_COMMIT subjects. Great. Where might I find what objects are
>> available via these notifications?
>> EOF's delegate has editingContextWillSaveChanges(EOEditingContext)
>> where if you throw an exception it will abort the save for the
>> context. How might a listener of the WILL_COMMIT changes event
>> achieve this? Note: this is not a question about validateForSave.
>
> DataContextTransactionEventListener and
> DataObjectTransactionEventListener are the listener interfaces for
> those events. They can abort the commit. Not sure in what form
> those will be preserved in 3.0 yet. Also these events are only
> available on the server.
How might they abort the commit? By simply throwing an exception?
>> More importantly - what's the best mechanism to (post validation
>> but pre actual commit) of actually making some final adjustments
>> to an object. e.g., something simple such as dateModified field. I
>> know we could put this into validateForSave but we call this many
>> times prior to saving on the server - actually whenever someone
>> makes a change in the gui (in order to highlight what might
>> prevent saving the object).
>
> One other very promising technique is decorating a DataChannel with
> an interceptor.
>
> Disclaimer: this hasn't been tested yet, but the facilities are
> there since 1.2. On the server it will work like 90% (and break in
> any method that relies on DataContext.getParentDataDomain()).
> However I think it should work on the client.
<...>
Thanks for the info. Shall look into that...
with regards,
--Lachlan Deck
This archive was generated by hypermail 2.0.0 : Wed Sep 06 2006 - 23:50:57 EDT