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.
<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.
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. But in any case, I think that states shouldn't give a damn about other states: transactions might need that.
Ciao,
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
