Re: [jira] Commented: (SLING-1137) Support hierarchical child node creation from SlingPostServlet

[John Norman <jo...@caret.cam.ac.uk>]

Non-developer warning:

On 7 Oct 2009, at 22:47, Alexander Klimetschek wrote:
> [...]
> But even if Jackrabbit scales with hundred thousands of child nodes
> per node, you still have the problem of an unbalanced tree: it will be
> hard or not to say impossible to browse that tree for a human - you'd
> need a very advanced paging tree view to be able to go through that)
> and just doesn't "feel" right. Well, at least to me ;-)

Does it make any difference that different users might have a  
different logical tree for organising the same content? I have seen  
quite a few hierarchical information organisation models that make  
sense to one human being but are completely unhelpful to another. I  
quite like the concept of an amorphous information pool that can have  
multiple apparent organisations according to viewer and context.

Re: [jira] Commented: (SLING-1137) Support hierarchical child node creation from SlingPostServlet

[Alexander Klimetschek <ak...@day.com>]

On Thu, Oct 8, 2009 at 00:24, John Norman <jo...@caret.cam.ac.uk> wrote:
> Does it make any difference that different users might have a different
> logical tree for organising the same content? I have seen quite a few
> hierarchical information organisation models that make sense to one human
> being but are completely unhelpful to another. I quite like the concept of
> an amorphous information pool that can have multiple apparent organisations
> according to viewer and context.

I agree: one just has to look at the different folder structures on
people's computers. The best one I have seen (and he is a developer!)
was to put everything flat on the desktop and after a while, when it
becomes full and old, he simply moved everything into an "old" folder
- on the desktop. Over time, this gives quite a few nested old
folders. Unusual but very simple... oh, I am getting off-topic ;-)

You could achieve multiple views with shareable nodes in JCR 2.0 plus
hiding the other nodes that point to the same structure depending on
the current user. But I don't think it's worth the effort. When you
have shared content you have to come up with a structure that is
useable for everyone (at least a bit). Here at Day we define the base
structure of the repository for our CQ5 product, a structure that
emerged through the product's history and follows many conventions
from the unix file system hierarchy (eg. short names are important).
Only at the lower levels customers are free to use a different
structure (for code and other non-site content stuff).

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com