Hi, On 3/27/07, Nandana Mihindukulasooriya <[EMAIL PROTECTED]> wrote:
Nope, Same image will not be attached to multiple Blog Entires. But if it is the case, as I understood I should use property of reference type in the blog entry which references to a image attachment. Is that the way to handle it ?
Yes. Such solutions are typically called image or document (or even digital asset) libraries in content management systems. In a JCR content repository such a library could conveniently be managed as a separate content tree, like /my:library. A good solution would be to make the image library consist of standard nt:folder and nt:file nodes to make it easily manageable. You can then for example mount the library subtree as a standard WebDAV folder using jackrabbit-jcr-server as the server. And since the nt:resource nodes within nt:files are referenceable, you can readily link to the images and other resources within the library.
1.) In naming node types and properties, do we follow the naming conventions used in Java ? Eg. myFristType
That's the precedent set by the JCR spec (for example nt:hierarchyNode), so it's a good convention to follow.
2.) What is purpose mixin node type ? Purpose of primary node is to define the structure of the node as I understood. What is the advantage of adding some properties or child nodes via mixin types to a node ?
The Java class/interface model mentioned by alartin is a good way to look at it, but there are two important differences. The first one is that Jackrabbit supports multiple inheritance, i.e. a primary type can inherit any number of both primary and mixin types. The second one is that you can dynamically add or remove mixin types of a node. I usually think of the primary type of a node as the primary definition of that node. The node should be perfectly usable with no dynamically added mixin types (note that the primary type can include mixin types like mix:referenceable if needed). Mixin types on the other hand can be used for adding extra "features" to a node. Such features would typically be orthogonal to the main purpose of the node. For example, if I have a standard nt:folder structure, I might decide that I want to make some folder referenceable, lockable, or versionable in which case I'd simply add the respective mixin type to that node. The folder would still work just as before, with just the extra functionality added.
3.) What is the purpose of primary item of a node type?
As alartin mentioned, it is mostly used to as a guide to applications. For example jackrabbit-jcr-server knows how to follow primary item definitions to decide which property to serve as the primary content of a node even though the implementation has little or no built-in knowledge of the node type semantics.
4.) In a property definition, in Required Type, what does NAME, PATH types mean ?
They are for storing JCR item names and paths in a way that is independent of particular namespace mappings. For example a path /foo:name would become /bar:name if the "foo" namespace mapping is modified. If the path was just stored as a "/foo:name" string, then it would become invalid when the prefix changes, but if it was stored as a PATH property, then Property.getString() on it would actually return "/bar:name" with the new prefix.
In CND notation, <blog = 'http://jackrabbit.apache.org/jackrabbit-jcr-demo/1.0'> <mix = 'http://www.jcp.org/jcr/mix/1.0'> [blog:user] > mix:referenceable - blog:userID (long) mandatory
You don't really need these ID numbers, they are likely a result of the earlier normalization process. In JCR all content items are always uniquely identified by their paths, and making a node referenceable adds a persistent UUID identifier that won't change even if the node is moved around.
+ blog:year [blog:year] multiple
Having custom node types for the intermediate nodes isn't really necessary, and could even be seen as detrimental. I would instead use a standard nt:folder hierarchy, with the added benefit of making the content tree more "familiar" to generic JCR tools. Something like this: + blog:content [nt:folder] mandatory autocreated Your application can then create the required yyyy/mm subfolders as needed. This approach would allow you to later change the substructure if needed.
[blog:blogEntry] - blog:blogEntryID (long) mandatory
Again, no need for the explicit ID number. If the entries need to be referenceable (would be a good idea for example to support unique identifiers in syndication feeds), then mix:referenceable is a better solution. To go with the above nt:folder solution I would also make the blog entries extend nt:hierarchyNode. [blog:blogEntry] > nt:hierarchyNode, mix:referenceable
- blog:content (string) mandatory
I would mark this as the primary item: - blog:content (string) mandatory primary
- blog:image (binay) multiple
Instead of a single binary property it would probably be better to use either a single nt:resource child node for the image or an nt:folder subtree that could support multiple attachments and even links (nt:linkedFile) to a document library as mentioned above. Something like this: + blog:attachments (nt:folder) mandatory autocreated
- blog:dateCreated (date) mandatory
If you made the node entries extend nt:hierarchyNode as mentioned above, you would get the standard autocreated jcr:created property for free.
[blog:comment] - blog:commentID (long) mandatory
Same as with the blog entries, drop the artificial identifier for mix:referenceable and use nt:hierarchyNode: [blog:comment] > nt:hierarchyNode, mix:referenceable BR, Jukka Zitting
