Guido Casper wrote:
Interesting. would you like to share that with us? I think it would be avery good exercise to see the two approaches one beside the other.
I don't have interest in generating my complete workflow logic out of a UML diagramm or a XML file. I remember there have been thoughts about generating flowscript out of a XML file describing my page flow logic, but I doubt that will ever happen. I can't grasp what that would give me (now that I have flowscript available :-).
For one, this might buy usage of some well-established worflow description languages, such as XPDL or BPEL: this would mean, in turn, being able to use existing tools to manage the workflow configuration.
This is a very important point IMO: workflow configuration shouldn't belong to programmers: it's a job for business people who shouldn't give a damn about Java/Javascript/XML, then need drawing tools.
That's perfectly fine. It just doesn't reflect my current use case :-) I can imagine something like that for workflow logic just not for page flow logic.
<workflow-manager> <state name="tobeprocessed" class="TobeprocessedState"> <entering-action class="TobeprocessedAction"/> </state> <state name="beingprocessed" class="BeingprocessedState"> <entering-action class="BeingprocessedAction"/> <leaving-action class="LeaveBeingprocessedAction"/> </state> <state name="tobereviewed" class="ToreviewedState"> <entering-action class="TobecheckedAction"/> </state> ... </workflow-manager>
I'm afraid it's not that simple. Your workflow allows only for a linear flow, where you have only one way to go in the opposite directions (back and forth). But quite often you need to be able to model n ways in or out, you might need conditionals, you might need vetoes, and so on and on: workflow is a messy beast to handle.
Gianugo, this configuration is not meant to be a description of my workflow.
It's a definition of what state objects are available. The actual workflow is made up of the State objects themselves (as I said, the workflow is coded in Java, not in XML). Actually "State object" might be misnamed (I just took it from the state pattern) as they don't hold any state (or other data) but get instantiated by the workflow engine when reading the current state of an object. They just hold the conditional logic. This means, looking at the state objects you don't see the overall workflow. But that's the whole idea. You just code isolated steps and decisions of workflow since every workflow may be broken down into isolated steps.
The alternative would be to have a giant nested case statement.
The major drawback currently is that my AbstractState has to know about all the other states (to prevent each State class having to know about all the other states) and (when adding NewState) has to be updated with: allowEnterNewState(doc, user) {return false;}
I have the gut felling that this may be solved with some piece of AOP but I don't know enough about AOP and I currently don't care enough as this already satifisfies my needs.
Of course any State object allowing transitioning to NewState has to be updated with the corresponding conditional logic (overriding allowEnterNewState). Each state has to know about other states it allows transitioning to and the conditional logic (if any) to do so.
This sounds a bit overwhelming, there are too many dependencies to account for and you end up with a very proprietary and not reusable code.
What depencies do you mean? Actually I found changing workflow very easy and flexible as long as you don't come up with new states.
It is true that the state objects themselves are not reusable (and are not meant to be) but so would be any construct describing the actual workflow (which is the only thing the state objects actually do).
But in any case, I think that states shouldn't give a damn about other states: transactions might need that.
Yes, maybe they are misnamed. Just replace "states" with "transaction" (or even better "transitions").
Guido
