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
