Hi Josias
Josias Thoeny wrote:
Hi,
There have been discussions before about how to represent the
hierarchical structure of a set of documents in Lenya.
I don't know if there has been a decision, I didn't find anything in the
mail archive. So I would like to raise this issue again.
This topic has to be seen in relation with how the workflow
will be designed. Please see below and remember the discussion
we had before how the workflow should be modelled.
Documents can be stored either in a hierarchical way, or in a flat way,
whereas the structure is stored separately:
1. flat storage:
---------------
repository:
- doc1
- doc2
- doc3
- doc4
site structure:
doc1-id
+- doc2-id
+- doc3-id
+- doc4-id
2. hierarchical storage:
-----------------------
repository:
doc1
+- doc2
+- doc3
+- doc4
Lenya 1.2 stores the documents hierarchically in the filesystem, but
also uses a sitetree.xml to represent the structure. It's a mixture of
option 1 and 2, and looks like knowledge-duplication to me. (Probably
good for performance, though)
With JCR, either option 1 or 2 are possible.
The advantage of the flat structure is that multiple views are possible.
As Felix said in an earlier email, it corresponds better to the MVC
pattern.
The idea was to use JCR workspaces for 'authoring' and 'live'. JCR
offers functionality to clone a node from one workspace to another,
keeping its UUID. To publish a document, this would have meant to
clone the node to the 'live' workspace or, if the node existed
there already, use JCR's update() method. Unfortunately, it's not
possible to use this method for single nodes but only for the
whole subtree. That's why a flat hierarchy was considered with
a separate hierarchical sitetree with references to the respective
nodes. You see, it was a rather technical based suggestion.
However, I think that in the case of Lenya the site structure is more
than "just" a view because it adds dependencies between documents. For
example, it is not allowed to delete a document which has children, or
it is not allowed to publish a document whose parent is not published
yet.
Actually I'm not really sure what this means w.r.t to the MVC pattern.
This has to be enforced in the controller.
IMHO the main difference between JCR and a relational DB is that JCR
allows hierarchical access. To me it seems a little strange to use JCR,
but store all documents on the same level.
Documents/Nodes will be accessed through any custom or built-in
navigational structure (like a sitetree).
Furthermore, I think that even with the hierarchical model it would be
possible to have alternative views. Such a view would reference the
documents by their UUIDs.
A first discussion was to store the nodes in a hierarchy but when we
realized that the clone/update mechanism will not work this way.
For me it's not really clear which is the best way, so I would like to
hear your thoughts/opinions.
Thanks for bringing up this issue again as it will be one of the main
design decisions in the cours of the JCR integration.
Josias
--
Felix Röthenbacher [EMAIL PROTECTED]
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
