jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Nuescheler" <da...@day.com>
Subject Re: Optimal structure
Date Wed, 22 Aug 2007 09:58:54 GMT
Hi Anton,

Thanks a lot for the additional information.

>  my hierarchy will contain building parts (actually content) for web portal
> - news,articles, interviews. maybe blogs.
Many of those items may have an internal structure.
Let me try to explain what I mean with an example
content structure...

/content/news/2007/08/21/somethingtoremember
/content/blogs/davidsblog/blogposts/veryinteresting
/content/articles/business/yourmoney/bankrupt

... or even something ...

/content/mywebsite/news/2007/08/21/somethingtoremember
/content/mywebsite/personalpages/davidsblog
/content/mywebsite/personalpages/davidsblog/blogposts/interviewwithanton
/content/anotherwebsite/aboutme/blogposts/mypost

> Every type of content has related type of node.
Well, some people like the act of defining nodetypes.
I personally don't. True to a data first approach,
I would probably start a lot of nt:unstructured in
the beginning and see how far I get until I need
to impose more structure through nodetypes.

> So end users will not work
> with repository directly - they will use usual functions of web portal -
> searching and viewing certain type of content.
Yes, I would certainly not recommend that end users
work directly with the content repository

> With jcr functionality will work facade (for example - session bean), wich
> will provide for web layer needed functions.
Sounds good. Maybe you are interested in Sling
http://wiki.apache.org/jackrabbit/SlingProposal

> 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?
Search performance is not impacted by the nature of the content hierarchy.

A number of read and update operations in jackrabbit are faster on nodes
with a smaller number of child nodes, but this is not really significant.

I would really recommend to try to use a meaningful hierarchy (see above)
instead of a flat model, for the sake of access control and other operations
that leverage the hierarchy.

regards,
david

Mime
View raw message