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
>
>
This archive was generated by hypermail 2.0.0 : Sat Oct 27 2007 - 13:02:26 EDT