jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: How to start thinking in JCR
Date Tue, 27 Mar 2007 09:04:36 GMT
Hi,

On 3/27/07, Nandana Mihindukulasooriya <nandana.cse@gmail.com> 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

Mime
View raw message