Hrm. I think an analogy/metaphor might help understand the CND vs OCM annotation issue.
The CND specification and language allows for specifying constraints and relationships between 'stuff' in the JCR. Its a bit like throwing a constraint on an RDBMS table with DDL, although a better idea would be to create a class of tables that share the same constraints and foreign keys.
OCM operates at a level or tier above the JCR, similar to ORM tools. Of course, all the varied ways of defining and typing objects apply, with much more flexibility than the JCR specs. But you don't get the namespace enforcement at the storage layer - which means a second tool that doesnt use your OCM implementation could violate constraints and namespaces established in your OCM implementation.
One of the questions I like to ask teams when starting projects is: Should we handle constraints at the storage layer or persistence layer? And which constraints where?
Juan Pereyra wrote:
Hi all, Here goes another question about the OCM. According to the documentation, one would define new namespaces and new nodetypes as part of an CND configuration. However, I noticed that most things that you define on the CND file, you could define them as annotations (i.e. jcrSuperTypes, etc.). Trying to get OCM to load the new types from annotations I got to the AnnotationDescriptorReader class, which JavaDoc is this: <code> /** * Helper class that reads the xml mapping file and load all class descriptors into memory (object graph) * * @author <a href="mailto:[email protected]";>Lombart Christophe </a> * @author : <a href="mailto:[email protected]";>Boni Gopalan</a> * */ public class AnnotationDescriptorReader implements DescriptorReader </code> However, the class reads annotation descriptors, not an XML, and interestingly enough, the JavaDoc is identical to the one in the class DigesterDescriptorReader. So, summarizing, is it possible to load namespace definitions without the CND or an XML? just with annotations? Everything that's needed seems to be there already. Many thanks guys! Juan
