hi!
i'm trying to implement proper checkout (aka locking) for tinymce.
andreas told me to
> - set the transaction policy of the usecase to "pessimistic"
> - return the document's repository node in getNodesToLock()
in order to find out how to do that, i looked for clues in other
modules. in webdav, i found the Put.java usecase handler, and i figured
the same locking that's good for webdav uploads should be ok for an
editor usecase as well. but it seems there is a whole bunch of nodes
being locked:
/**
* @see org.apache.lenya.cms.usecase.AbstractUsecase#getNodesToLock()
*/
protected Node[] getNodesToLock() throws UsecaseException {
try {
Document doc = getSourceDocument();
List nodes = new ArrayList();
NodeSet set = SiteUtil.getSubSite(this.manager,
doc.getLink().getNode());
Document[] documents = set.getDocuments();
for (int i = 0; i < documents.length; i++) {
nodes.add(documents[i].getRepositoryNode());
}
SiteStructure structure = getSourceDocument().area().getSite();
nodes.add(structure.getRepositoryNode());
return (Node[]) nodes.toArray(new Node[nodes.size()]);
} catch (Exception e) {
throw new UsecaseException(e);
}
}
let me see. i edit a document
"mysite.org/mypub/authoring/some/path/to/foo.html".
does that mean i have to lock "/some.html", "/some/path.html",
"/some/path/to.html" and finally "/some/path/to/foo.html"?
i can see how that made sense with the old repository implementation,
but is it really necessary now that we have moved to UUIDs and each
document is addressed directly?
the answer probably depends on how we want to handle sitetree updates.
there was some discussion about this a while ago, but i can't remember
what was decided.
if i lock all those nodes, i can be sure that nobody makes changes to
the relevant sub-sitetree while somebody is editing a file. but it also
means that when someone is editing *any* document, you can't edit any of
its ancestors, right?
help!
jörn
--
Jörn Nettingsmeier
"Hofstadter's Law: It always takes longer than you expect,
even when you take into account Hofstadter's Law."
- Douglas R. Hofstadter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
