This is correct in general, but there's no hard rule on overriding (and we didn't mark these methods as "final"). A user may override those methods as long as he doesn't change their underlying behavior, so that Cayenne still functions correctly. E.g. a user may override them to trace access to specific properties, etc.
Andrus On Feb 1, 2011, at 3:13 AM, Andrew Lindesay wrote: > Hi Andrus; > > Maybe the following two method comments may help other people understand what > these methods are for... > > --- > > 1) readProperty > > <p> > This method exists for the benefit of the framework. It will allow > properties of the data object to be read. This method is not intended to be > overridden to provide additional functionality. Some processing such as > faulting may occur in addition to the data being returned. If there is no > value for a property then <code>null</code> will be returned. Null will also > be returned in cases where the a property is requested which is not modelled. > </p> > > --- > > 2) readPropertyDirectly > > <p> > This method exists for the benefit of the framework. It will allow > properties of the data object to be read. This method is not intended to be > overridden to provide additional functionality. Additional processing such > as faulting will not occur as part of retrieving this property. If there is > no value for a property then <code>null</code> will be returned. Null will > also be returned in cases where the a property is requested which is not > modelled. > </p> > > --- > > Is that about right? > > It is a bit of a shame that I want to implement "readProperty" and this is > already taken by the framework! > > cheers. > >> Yeah, probably need to think about it. At the same time it is great when new >> extensions are created on top of Cayenne "platform", so if you implement an >> open source key-value-coding extension package solving specific problems, >> definitely mention it to the community. > > -- > Andrew Lindesay > www.silvereye.co.nz >
