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 Mon, 09 Apr 2007 05:20:22 GMT

On 4/9/07, Nandana Mihindukulasooriya <nandana.cse@gmail.com> wrote:
> > Also, there's a chance to drop the explicit blog:library and
> > blog:blogSpace child node definitions if you make blog:user extend
> > nt:folder. Then you could simply have "library" and "blog" subfolders
> > within the user node, or even avoid those subfolders entirely and rely
> > on node types to detect which child nodes are blog entries and which
> > are other resources.
> Does it mean a structure like,
>  /blogRoot/user/ <yyyy>/<mm> /blogEntry [blog:blogEntry]
>  /blogRoot/user/<avatar.gif> [nt:file]
>  Or a structure like,
>  /blogRoot/user/blogEntry [blog:blogEntry]
>  /blogRoot/user/<avatar.gif> [nt:file]
> In the latter one, are we using the jcr:created property of  nt:hierarchyNode
> if we want to list the blog entries according to date or month.

I would use the former structure (with yyyy/mm) as discussed in
previous messages. In any case, for date-based listings it makes sense
to use a subtree query like
"/jcr:root/blogRoot/user//element(*,blog:blogEntry) order by
@jcr:created" to avoid hardcoding the folder structure in your
application. The yyyy/mm structure is more designed to avoid too many
child nodes in one place and to make it easier to administer the
content, not that much as a way to organize normal read access.

> > It's a tradeoff between flexibility and more
> > completely specifying the content structure.
> >
> > I would actually suggest we take this opportunity for extra
> > flexibility since it gives some very nice late binding benefits when
> > we later start defining the URL mapping for the application.
> >
> By flexibility, does it mean the flexibility we have to change the structure
> as we want in the future ? How does this help to get the late binding
> benefits?

The benefit is that without the explicit blog:blogSpace and
blog:library subfolders, we can do a clean and direct URL to path
mapping without any hardcoded information about the application
structure. Consider the URL space for such a blog application:

    .../jukka/ -> /blogRoot/jukka [blog:user]
    .../jukka/2007/04/hello/ -> /blogRoot/jukka/2007/04/hello [blog:blogEntry]
    .../jukka/2007/04/hello/world.pdf ->
/blogRoot/jukka/2007/04/hello/world.pdf [nt:file]
    .../jukka/avatar.png -> /blogRoot/jukka/avatar.png [nt:file]

The URLs are "clean" and map one-to-one to nodes in the repository.
And the best part is that you don't need to put any custom "a URL like
this should be processed like this" rules in your application, as you
can just use the primary node type of the target node to select the
appropriate view component for displaying the node contents.

> [blog:user] >  nt:hierarchyNode, mix:referenceable

Use nt:folder instead of nt:hierarchyNode as the parent type to allow
the custom substructure described above.

> [blog:blogEntry] > nt:hierarchyNode, mix:referenceable
> - blog:title (string) mandarory primary
> - blog:content (string) mandatory
> - blog:rate (long)
> + blog:attachments (nt:folder) =nt:folder mandatory autocreated

Here we could do the same thing, allow attachments directly below the
blog entries without the intermediate blog:attachments folder. Just
change the supertype from nt:hierarchyNode to nt:folder. This also
allows us to place the comments as nt:hierarchyNode subnodes within
the same subtree.

You might also want to consider custom created/published/updated
timestamp properties, as the standard jcr:created is somewhat
inflexible (once created it can't be modified).

>  [blog:comment]
> - blog:content (string) mandatory primary
> - blog:commenter (reference ) mandatory  < blog:user

Add "> nt:hierarchyNode" to allow comments to be stored as normal
child elements of the nt:folder blog entry node.


Jukka Zitting

View raw message