Josias Thoeny schrieb:
On Tue, 2006-01-31 at 11:20 +0100, Andreas Hartmann wrote:
Josias Thoeny schrieb:

[...]

One problem I see is the parent-child relations.
For example, now it's not possible to publish a document if its parent
is not published. This guarantees some kind of "integrity".
If you have multiple hierarchical site structures, you cannot have this
kind of dependency constraints.
I think that would be possible. The current SiteManager interface
allows to define a dependency relation, which could be implemented by
all site structures to ensure integrity constraints.

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?

-- Andreas


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

Reply via email to