You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Felix Röthenbacher <fe...@wyona.com> on 2005/04/07 11:44:37 UTC
SiteTree interface change proposal
Hello
while working on the integration of Jackrabbit into Lenya
I stumbled over some issues with the SiteTree interface
definitions that are not compatible in the way a repository
handles nodes.
1. Stale nodes after node removal
One Problem is that SiteTree.removeNode() returns the removed
SiteTreeNode. When working on the repository, a node is
physically removed from the repository and the returned
SiteTreeNode object state is invalid. I suggest to set
SiteTree.removeNode() to deprecated and introduce a
new method called deleteNode() which does not return
any value. See below:
/**
* Remove the node with given document id from tree.
*
* @param documentId The document-id of the node that is to be removed
*/
void deleteNode(String documentId);
2. Replace importSubtree() with copy/move methods
SiteTree.importSubtree() is currently used to implement
copy and move operations on the sitetree. I suggest to
set importSubtree() to deprecated in favour of two
new methods copy() and move(). These methods allow
a sitetree implementation to use methods available
in the repository implementation used. Therefore,
a much more efficent and intuitive implementation
of copy/move operations is possible. A proposed
method signature follows:
/**
* Copy a node with all its child node.
* @param src Node to copy.
* @param dst Parent node where node will be inserted.
* @param newId The new id of the inserted node (in case when the node
* id exists already).
* @param followingSibling The sibling node that should follow this
* node (ordering), if null the node will be inserted at the end.
*/
void copy(SiteTreeNode src, SiteTreeNode dst, String newId,
String followingSibling) throws SiteTreeException;
/**
* Move a node with all its child node.
* @param src Node to move.
* @param dst Parent node where node will be moved to.
* @param newId The new id of the moved node (in case when the node
* id exists already).
* @param followingSibling The sibling node that should follow the
* moved node (ordering), if null the node will be inserted at the
* end.
*/
void move(SiteTreeNode src, SiteTreeNode dst, String newId,
String followingSibling) throws SiteTreeException;
One issue is that nodes may be copied between different sitetrees.
The implementation has to take care of this and copy/move the
nodes to the appropriate sitetree (aka area, aka workspace).
I think that the proposed interface changes will benefit the
integration of a content repository and will result in a
more intuitive use of the SiteTree interface.
Any comments on this topic are very welcome!
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: SiteTree interface change proposal
Posted by Andreas Hartmann <an...@apache.org>.
Felix Röthenbacher wrote:
> Hello
>
> while working on the integration of Jackrabbit into Lenya
> I stumbled over some issues with the SiteTree interface
> definitions that are not compatible in the way a repository
> handles nodes.
>
> 1. Stale nodes after node removal
>
> One Problem is that SiteTree.removeNode() returns the removed
> SiteTreeNode. When working on the repository, a node is
> physically removed from the repository and the returned
> SiteTreeNode object state is invalid. I suggest to set
> SiteTree.removeNode() to deprecated and introduce a
> new method called deleteNode() which does not return
> any value. See below:
>
> /**
> * Remove the node with given document id from tree.
> *
> * @param documentId The document-id of the node that is to be removed
> */
> void deleteNode(String documentId);
+1
IMO its a bad practise to return values from methods with
side effects anyway (except maybe boolean success notifiers).
> 2. Replace importSubtree() with copy/move methods
>
> SiteTree.importSubtree() is currently used to implement
> copy and move operations on the sitetree. I suggest to
> set importSubtree() to deprecated in favour of two
> new methods copy() and move().
> These methods allow
> a sitetree implementation to use methods available
> in the repository implementation used. Therefore,
> a much more efficent and intuitive implementation
> of copy/move operations is possible. A proposed
> method signature follows:
>
> /**
> * Copy a node with all its child node.
> * @param src Node to copy.
> * @param dst Parent node where node will be inserted.
> * @param newId The new id of the inserted node (in case when the node
> * id exists already).
> * @param followingSibling The sibling node that should follow this
> * node (ordering), if null the node will be inserted at the end.
> */
> void copy(SiteTreeNode src, SiteTreeNode dst, String newId,
> String followingSibling) throws SiteTreeException;
>
> /**
> * Move a node with all its child node.
> * @param src Node to move.
> * @param dst Parent node where node will be moved to.
> * @param newId The new id of the moved node (in case when the node
> * id exists already).
> * @param followingSibling The sibling node that should follow the
> * moved node (ordering), if null the node will be inserted at the
> * end.
> */
> void move(SiteTreeNode src, SiteTreeNode dst, String newId,
> String followingSibling) throws SiteTreeException;
>
> One issue is that nodes may be copied between different sitetrees.
> The implementation has to take care of this and copy/move the
> nodes to the appropriate sitetree (aka area, aka workspace).
Would this be implemented using remove() from one tree and add()
to another tree? If yes, how would it be solved to transfer all
(internal?) information that is attached to the tree nodes?
The importSubtree() method is similar to org.w3c.dom.Document.importNode(),
I guess the guys at W3C already came across the problem.
> I think that the proposed interface changes will benefit the
> integration of a content repository and will result in a
> more intuitive use of the SiteTree interface.
I agree. BTW, in 1.4 the SiteManager interface is used for such operations.
Copying nodes is done using
/**
* Copies a document in the site structure.
* @param sourceDocument The source document.
* @param destinationDocument The destination document.
* @throws SiteException when something went wrong.
*/
void SiteManager.copy(Document sourceDocument, Document destinationDocument)
throws SiteException;
The internal details are hidden. In usecases, you usually use the
DocumentManager to copy documents, which even hides the handling of the
site structure, for instance:
/**
* Copies a document to another location, incl. all requiring documents. If
* a sitetree is used, this means that the whole subtree is copied.
* @param source The source document.
* @param target The target document.
* @throws PublicationException if an error occurs.
*/
void copyAll(Document source, Document target) throws PublicationException;
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: SiteTree interface change proposal
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Felix Röthenbacher wrote:
> I think that the proposed interface changes will benefit the
> integration of a content repository and will result in a
> more intuitive use of the SiteTree interface.
>
> Any comments on this topic are very welcome!
this makes me wonder if we need the sitetree interface in the future?
could we not just use a combination of jcr and site manager instead?
a while ago, it was pointed out how the sitetree is a one-off dom api,
which really does not make that much sense.
-gregor
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org