Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of antongavazuk@gmail.com
 designates 209.85.162.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=REvbYUDtnAm9tIFnCN90vh3nd7VeKg92WqITprxa+AA8r7gYRDTE1VXJ7q5x1xyCNr2qg9sWDzm2chefkMV2g6RfcVHNJEi047KV/v9LSsEFk4RiCzI9arUB7OCDrB0j0Rn8SbuKcG9TXo94Zk0jWwzjcjY2KS4Blobsime8LYs=
Message-ID: <b82b8560708151330x1a66a332xc3d33655ac4d284b@mail.gmail.com>
Date: Wed, 15 Aug 2007 23:30:05 +0300
From: "Anton Gavazuk" <antongavazuk@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: Optimal structure
In-Reply-To: <1b0d43d00708150712u7ca5bf8fs23dcdcbe7ce20ea2@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_61624_31013736.1187209805770"
References: <b82b8560708100300y79dc3a1bv2ea6b7a180b52ceb@mail.gmail.com>
	 <1b0d43d00708110145y1efdc18cr6ccd2b4a206dffa@mail.gmail.com>
	 <b82b8560708121245r297f1353y2dd4815dbf827bd9@mail.gmail.com>
	 <1b0d43d00708150712u7ca5bf8fs23dcdcbe7ce20ea2@mail.gmail.com>

------=_Part_61624_31013736.1187209805770
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi David,
 my hierarchy will contain building parts (actually content) for web portal
- news,articles, interviews. maybe blogs.
Every type of content has related type of node. So end users will not work
with repository directly - they will use usual functions of web portal -
searching and viewing certain type of content.

With jcr functionality will work facade (for example - session bean), wich
will provide for web layer needed functions.

So if I put all node types under one main root - it will be mistake? Or
better choice is providing related parent nodes for each category? Will
affect the structure of repository on prefomance of searching?


2007/8/15, David Nuescheler < david@day.com>:
>
> hi anton,
>
> sorry for the delay.
>
> i would be interested to understand the actual business
> requirement that you are trying solve...
> the hierarchy of nodes does not so much depend on property
> types used, but really on how can the hierarchy be of value for
> the business problem that you are trying to solve for your users.
>
> so if you can explain a little bit more in detail what it is that your
> application
> does and how your users are going to use it. from a hierarchy perspective
> i think it is important that you structure things as intuitively as
> possible
> for the end user.
>
> a good hierarchy, is self explanatory to the user of the application. so
> if you end users should ever see the content hierarchy directly, they
> should
> say: "i get it..." without any further explanations.
> they should feel at home, just like with the filesystem structure on their
> local harddisks...
>
> regards,
> david
>
> On 8/12/07, Anton Gavazuk < antongavazuk@gmail.com> wrote:
> > Hi David,
> >
> > I am going to save a lot of different type nodes  in repository.
> > The nodes will have 2 main property - name and body - both are String
> type.
> > And search will be carried out on these properties.
> > The differences between types - comments allowed or not.
> >
> > So, I'm  searching a faster scheme .
> >
> > P.S. What can I add to make my description more precise?
> >
> >
> >
> > 2007/8/11, David Nuescheler <david@day.com>:
> > >
> > > hi anton,
> > >
> > > this all depends on the actual usecase...
> > > can you be more specific about what you are trying to achieve
> > > and explain your application a little bit in details?
> > >
> > > regards,
> > > david
> > >
> > > On 8/10/07, Anton Gavazuk < antongavazuk@gmail.com> wrote:
> > > > Hello all!
> > > > I have the question about optimal structure of repository
> > > >
> > > > root
> > > >       nodeTypeA
> > > >       ...
> > > >       nodeTypeB
> > > >       ...
> > > >       nodeTypeC
> > > >
> > > >
> > > > or
> > > >
> > > > root
> > > >      rootForA
> > > >            nodeTypeA
> > > >            ...
> > > >      rootForB
> > > >            nodeTypeB
> > > >            ...
> > > >      rootForC
> > > >            nodeTypeC
> > > >            ...
> > > >
> > > >
> > > > Is there anything which can impact on prefomance or on
> maintainability?
> > > >
> > >
> >
>

------=_Part_61624_31013736.1187209805770--