Hi Tako,
Is this something that could generically be expanded to more elaborate workflows? Would you make a workspace for each state the document can be in for example? Well probably only those where you actually need to access the data I imagine, no need to get the contents for documents that are in "Waiting for review" for example.
This is generally how we model it. I would like to mention two specifics though.
(1) The number of steps that require promotion into a new workspace is relatively limited (in our general WCM case, there are only two workspaces) (2) our Workspaces can live in different repositories, so we actually replicate the content over the network from one repository to the other. Basically a remote "pushed" Node.update() operation.
Just wondering, I never thought about workspaces much so I have no good idea how to use them and was in fact planning on implementing a "workflow" mixin that would add a "state" attribute because that's how we implemented it in our old system, but this thread has made me realize that you would be searching in the version history which was cheap in our system but might not be for a JCR.
I still think that the mixin is a reasonable plan. Can you explain how this would be related to searching the version history?
An article on how to do workflows in a JCR would be nice too :-)
Agreed ;) regards, david
