Hi, On 7/14/06, Christophe Lombart <[EMAIL PROTECTED]> wrote:
Maybe not for the basic objects. It is will be more interesting when we will add new modules (news, forum, custom applications,....). Futhermore The object model (aka data objects) should be independant on the persistence layer.
Yes, but do you require the persistence layer to implement the model interfaces using pure data objects? Then why not define the data objects themselves as the API and just get rid of the interfaces? After all, there is only one reasonable data object implementation of for example the CmsObject interface.
Why do you want to add specific JCR code in the data objects ? I don't like the idea to add specific implementation in data objects. Thoses objects should contain only attributes with their getter/setter.
I'm probably missing something, so please hang on with me... As far as I've understood, your components use the interfaces defined in org.apache.portals.graffito.model in the api subproject. Thus for example they call CmsObject.setProperty() to set a generic string property. Why should this call be first routed to a Java setter and only then mapped to a JCR Node.setProperty() call by the OCM tool?
> That's what I was asking. :-) Is there a component that uses the > features of the underlying storage outside the API defined in the core > model? not yet. This is a good question. Do you see some use cases which will require this ?
Not really, just checking. If something like that is needed, then it's best handled by extending the core model. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
