On Sep 5, 2006, at 12:18 PM, Lachlan Deck wrote:
> 1) Are initial values set with server code propagated to clients
> when an object is created on the client?
>
> The following url...
> http://cwiki.apache.org/confluence/display/CAY/Setting+Initial+Values
>
> ... suggests using "public void setPersistenceState(int)" for
> setting initial values when state is NEW. I assume this is the
> equivalent of EOFs awakeFromInsertion(EOEditingContext).
>
> The above method is not triggered on the client (i.e., it's never
> called) - so my question is whether (in having this code on the
> server) these values will be available initially to the client
> context or not?
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. However
'setPersistenceState' is called on the client when an object is
created. Not sure why you are not seeing it.
> 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.
I wonder if we should instead add another pre-commit subject to the
DataChannel events that are here to stay and work the same way on the
client and on the server?? This may be the simplest solution...
> 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.
Example of context creation on the client:
ClientChannel channel = ...
DataChannelDecorator decoratedChannel = new DataChannelDecorator
(channel);
ObjectContext context = new CayenneContext(decoratedChannel);
Example decorator (missing event support):
public class DataChannelDecorator implements DataChannel {
protected DataChannel channel;
public DataChannelDecorator(DataChannel channel) {
this.channel = channel;
}
public EntityResolver getEntityResolver() {
return channel.getEntityResolver();
}
public EventManager getEventManager() {
return channel.getEventManager();
}
public QueryResponse onQuery(ObjectContext originatingContext, Query
query) {
return channel.onQuery(originatingContext, query);
}
public GraphDiff onSync(ObjectContext originatingContext,
GraphDiff changes, int syncType) {
System.out.println("**** Sync in progress");
return channel.onSync(originatingContext, changes, syncType);
}
}
Andrus
This archive was generated by hypermail 2.0.0 : Wed Sep 06 2006 - 03:46:53 EDT