OK, lets do this in several steps. The first step would be eliminating
difference between client (PersistentObject) and server (CDO). This also is
part of major goal of eliminating superclass.
In my view this first step is:
1. Moving methods from CDO up to PersistentObject, making PersistentObject
implement DataObject.
2. Eliminating what we can from DO interface ("snapshotVersions"?)
3. Making sure client classes now can act as server classes WITHOUT any
change (i.e. if they extend PersistentObject).
4. Deprecating CDO and start using current client VM's instead of server
ones
After that, we can :
5. remove all usages of DO.read/write Property, add/removeToManyTarget etc
from server code. Ensure DO interface is not used internally. it will make
the only imperative that classes implement Persistent
2009/11/19 Andrus Adamchik <andru..bjectstyle.org>
> No question, this can be useful. Where this gets in the way is with our
> elusive goal of providing persistence for POJOs without a framework-mandated
> superclass.
>
> The good news is that ClassDescriptor design can accommodate any type of
> objects (as long as you can force it to use ObjectContext callbacks). So
> while it is beneficial to eliminate object structural gap between ROP and
> "normal" Cayenne, it looks like support of separate hierarchies of POJOs
> (preferably without framework superclass), and generic objects is in our
> future (unless we totally give up on the POJO idea and keep extending
> CayenneDataObject everywhere).
>
> Now, if we do support both types of objects across the entire stack, it
> will be a user's choice what to inherit from (and as a result either use
> read/writeProperty methods or not).
>
> Andrus
>
>
>
> On Nov 19, 2009, at 1:12 PM, Andrey Razumovsky wrote:
>
>> 2009/11/19 Andrus Adamchik <andru..bjectstyle.org>
>>
>> Also Cayenne's own object access since 3.0 is fully based on pluggable
>>> ClassDescriptors, so declaring read/writeProperty on the object is not
>>> needed for Cayenne, and technically only the generic objects need such
>>> user-facing methods.
>>>
>>>
>> For that, I'll disagree. I've used DataObject.read/writeProperty a lot in
>> my
>> code for unified processing of DataObjects (non-generic) and prefer those
>> method stay in interface (moreover, appear in client-side objects). Vice
>> versa, read/writeProperty methods should through ClassDescriptors
>>
>
>
-- Andrey
This archive was generated by hypermail 2.0.0 : Thu Nov 19 2009 - 08:12:44 EST