Jörn Nettingsmeier wrote:

Andreas Hartmann wrote:

Josias Thoeny schrieb:

The constraints are derived from the site structure, which is a directed
acyclic graph. If there are multiple site structures, the constraints
must be derived from the union of all those graphs, which is not acyclic
anymore.


This is of course true, but does it present a problem?

See this simple example with docs A and B:

/struct1/A/B.html
/struct2/B/A.html


In this case, not either A or B can be deleted, only both of them.
It would be possible to generate a message like:

Node A cannot be deleted because it is required by other nodes:

- in struct2 by node B
- ...

[ Cancel ]
[ Delete All Nodes ]

The second option could start a "snowball mechanism" (IIRC there is
an Enlish idiom for this), and you might end up with deleting the
whole site. I agree that this is difficult to handle by the average
user.

Now we have a cyclic dependency between A and B. How could this be solved?
We could say it's not allowed to insert A->B if we have B->A in another
site structure, but that would be confusing to the user.
The other option I see is to drop the constraints for all but one of the
site structures, and perform operations like "delete" or "publish
subtree" only on that "main" structure.


IMO these concerns are valid. They can certainly be solved from
the developer's point of view, but usability is a different story.
What do the others think?


i think that lenya has too many real problems right now to think about virtual ones. there should be one canonical site structure, period. (it may even be flat).


I guess by the canonical site structure you mean the repository structure, right?

Michi


--
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
[EMAIL PROTECTED]                        [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to