The drawback to that approach is that other access paths to the repo are not attached to the workflow (of course you can do things like routing your WebDAV traffic through Cocoon).
Well, going through a repository layer on the Cocoon side does not mean the actual workflow data cannot be persisted in the form of properties on the repository (WebDAV properties in Slide this case). So I don't see a big problem there.
Well, the workflow might employ some kind of authorization, such as a user is only allowed to edit a document if he took that document into the "beingprocessed" state.
If you pass by the workflow by directly accessing the repo (for instance with a WebDAV tool) you would pass by that authorization layer.
So what might such a WorkflowManager look like? Our WorkflowManager (and I hereby propose to follow that path :-) is implemented as a Avalon component with the following interface:
-setState(docURI, requestedState, user, optionalObject)
-getState(docURI)
-getAllowedActions(docURI, user)
-setRepo(repo)
I hope the general meaning of the parameters is clear (and the details may be discussed later). "docURI" might be just an object identifier or an object carrying things like doctype information (so that your second precondition is met). "requestedState" might be a State object, an Action object, an Event object, simply a string or whatever. "optionalObject" in our case is string carrying a comment.
I think the repository is implementation specific and shouldn't be part of the interface.
Agreed.
Guido
The user might also be regarded as an aspect of the manager's state but I am less sure of that.
-- Unico
-- Guido Casper ------------------------------------------------- S&N AG, Competence Center Open Source Tel.: +49-5251-1581-87 Klingenderstr. 5 mailto:[EMAIL PROTECTED] D-33100 Paderborn http://www.s-und-n.de -------------------------------------------------
