Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of david.nuescheler@gmail.com
 designates 64.233.166.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=sHbiOY/km7ZmWs1M/cGMO4dDDDxyEjMTJ/nCtrlQ9U310sdicJXxWWMHmlW857MrieXVrK0UM6Vz4dobshaWrXlPgJpy1zcLv+Ai8Wd3GLKqeOmoIMuZAZHkmXXhJGeXLOqq+1jfYde7ca+XPVJXJk5KO4Bn+jLQfcqniRQUtlU=
Message-ID: <eb7e2190707070407x25f94b90hb47ae74155c4ec32@mail.gmail.com>
Date: Sat, 7 Jul 2007 13:07:30 +0200
From: "David Nuescheler" <david.nuescheler@gmail.com>
To: users@jackrabbit.apache.org
Subject: DM Rule #2: Drive the content hierarchy, don't let it happen.
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Explanation
---
The content hierarchy is a very valuable asset. So don't just let it
happen, design it. If you don't have a "good", human-readable name for
a node, that's probably that you should reconsider. Arbitrary numbers
are hardly ever a "good name".

While it may be extremely easy to quickly put an existing relational
model into a hierarchical model, one should put some thought in that
process.

In my experience if one thinks of access control and containment
usually good drivers for the content hierarchy. Think of it as if it
was your filesystem. Maybe even use files and folders to model it on
your local disk.

Personally I prefer hierarchy conventions over the nodetyping system
in a lot of cases initially, and introduce the typing later.

Example:
---
I would model a simple blogging system as follows. Please note that
initially I don't even care about the respective nodetypes that I use
at this point.

/content/myblog
/content/myblog/posts
/content/myblog/posts/what_i_learned_today
/content/myblog/posts/iphone_shipping

/content/myblog/comments/iphone_shipping/i_like_it_too
/content/myblog/comments/iphone_shipping/i_like_it_too/i_hate_it

I think one of the things that become apparent is that we all
understand the structure of the content based on the above example
without any further explanations.

What may be unexpected initially is why I wouldn't store the
"comments" with the "post", which is due to access control which I
would like to be applied in a reasonably hierarchical way.

Using the above content model I can easily allow the "anonymous" user
to "create" comments, but keep the anonymous user on a read-only basis
for the rest of the workspace.