On 7/14/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
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?
Ok I think there are some confusions here - sorry ! If you review the OCM tools, look only in JCR/mapping and JCR/spring. Other subprojects API, components, engine, ... are used for the Graffito core services (the content plateform itself). The OCM stuff is not yet integrated in this layer. Thoses core services are not only focusing on JCR repo. Developers can plug propriatary repositories. One Graffito goal is to group in the same "virtual content tree" different content servers. Some of them can be JCR repo and others can be propriatary. CmsObject is specific to this layer. if you check the OCM unit tests (/components/src/test), this is not mandatory to implements a specific interface and/or a specific ancestor class. You are free to defined your own. -- Best regards, Christophe
