cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lachlan Deck <lach...@ish.com.au>
Subject Re: Default/Initial values && post validation delegates etc
Date Thu, 07 Sep 2006 03:28:41 GMT
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



Mime
View raw message