Would be nice if we could make it work... IIRC back in the day when
ROP was first implemented there were a number of limitations
preventing DataContext and CayenneDataObject from being used on the
client, mostly related to the fact that both had direct dependencies
on the structure of the underlying stack (e.g. referencing DataDomain
and DataNode). Now we are *mostly* free of those. So I'd be curious
to try and use DataContext on the client.
A few issues to pay attention to:
* Serialization. Current client objects are more lightweight as they
store their properties in Java fields, vs. a Map used by
CayenneDataObject. So probably a custom serializer is needed.
* While supporting a single class hierarchy is a good idea,
preserving the ability for separate hierarchies is very important -
users may not want to expose some server methods to the client, and
generally may want to have two sets of objects with different behavior.
In any event it is a good idea to reevaluate our options now.
Andrus
On Oct 27, 2007, at 7:20 PM, Kevin Menard wrote:
Hi all,
I've just gone back to work on a ROP application I have and am
again running
into the issue of having to duplicate code between the server model
subclasses and the client model subclasses. I've got a way of working
around that, but I'm thinking this is probably best handled by
Cayenne. In
particular, I really don't think that there should be two class
hierarchies
for what amounts to a boolean field (remote/not remote).
I think the generated superclass should perform the duty of calling
the
appropriate method for reading and writing properties. I think
this would
advocate adding an isRemote() method to the ObjectContext interface
to avoid
having to do instanceof operations.
There would have to be some sort of unification between
PersistentObject and
CayenneDataObject as well. My naïve guess is that the latter could
extend
the former, but I haven't investigated whether or not they are
compatible.
Does this sound like a reasonable approach? If so, I'll probably
dig in on
that.
Thanks,
Kevin
