[EMAIL PROTECTED] schrieb:
=== Text from other discussion
The hierarchical index must exist, but does not need to be reflected
I am unsure whether such an index must / should exist. It certainly is
the case in the default publication, but would it be true in general ?
My feeling is:
it should be the responsibility of the site API to provide information
such as:
- what document(s) should I present to the user as a start page (the
bootstrapping)
- given a document X, what should be presented as "child" documents of
document X ? (in certain publications, this response may vary depending
on context, such as user type)
In the default publication, this information is provided by reading the
sitetree.xml (or the corresponding JCR representation of the site tree).
Other publications could implement this API entirely differently, for
example without relying on a fixed tree. For example, I have a use case
as follows: the user clicks on a document in the navigation menu; it is
only at this stage that I can (dynamically) determine what the child
documents to be presented in the current situation are.
What does exist in this situation, as in the default publication
situation, is a tree of all nodes the user has opened (and can thus be
rendered as a navigation menu)
(...)
An alternative would allow a document to have several parents:
> (...)
getPrimaryParent(UNID)
getAllParents(UNID)
getAllChildren(UNID)
getAllPrimaryChildren(UNID)
First, yes IMO a document should be allowed to have several parents
(document reuse). This is especially important if we allow a document to
consist of several document pieces (which I hope we can achieve in the
next generation).
But actually, I wonder at which point we have to know what a document's
parents are ? Isn't it sufficient to know, for a given document, what
it's children are ? Maybe you are referring to access rights, such as:
if a document has no specific access rights, use its parent's access
rights to decide whether the user may see it. Do I understand correctly ?
This access right mechanism would be publication dependent. In the
current default publication, the parent is known from the URL. Other
publications, potentially using other navigation mechanisms, would have
to implement access decisions based on their specific navigation mechanism.
(...)
The multiple-parent index would look like:
/foo
/foo/aaa
/other1
/other1/aaa
/parent2
/parent2/other2
/parent2/other2/aaa
This allows a document to appear at several places in the hierarchy.
Sounds fine to me -
whereas, what I'm trying to say is: I don't think we need to change the
default publication right now to allow it to support multiple parents. I
do however think we should not implement anything in the core / JCR
storage / etc. which would disable the usage of multiple parents as
such. And we should try to make the Lenya 1.4 core API flexible enough
so as to not make any assumptions regarding a fixed, predetermined 1-n
parent-child structuring.
(...)
If we want to allow multiple parents, this functionality should be
designed into the core as early as possible. Adding it later could
require rewriting many basic functions. Specifically it means the
addition of a Document property to store the multiple parents, and
support for multiple indexes.
Well, I'm not sure that this is what it means :) Again, we have to
distinguish what is publication dependant, and what is general (core).
Unfortunately I admit that I currently lack the knowledge to say "we
must change exactly this and that in the core API to achieve this goal".
This touches upon the discussions regarding scope of Lenya in the past
days. I actually agree with everyone ;) The default publication can be
used as a CMS for "common" Web sites (such as ours, used for
straightforward information delivery, of well-known and structured
information). But the particular added-value of Lenya should be the fact
that it can be used as a CMS framework, that's why it's important to
keep non-default-publication needs in mind, even if they appear strange
or uncommon :)
(...)
solprovider
Thx for your thoughts
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
