Guido Casper wrote:Gianugo Rabellino wrote:<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.
Doesn't quite looke like that:
Yes, sorry maybe I should have mentioned that more explicitely.
you seem to be mixing states and transitions, by explicitely telling States which are the back and forth states (here transitions are opaque).
No, that's not the case.
IMO you should have lists of states,
That's what I (believed to) have.
list of transitions
Since any state might have n outgoing transitions I coded the outgoing transitions into the state objects (and therefore maybe they are better named transistions :-).
and then something to glue them together
And that will always be the most nasty part.
The way I did it, is that the actual states are no objects, but simply strings. What should a state object do anyway? (I'm trying to learn). In the same sense, what should a transition object do if it's not actually "glueing something together". _Any_ combination of 2 states is a potential transition (I believe I don't need all these extra objects because I don't code in XML but in Java). When the workflow engine encounters a state defined within the configuration, it asks the state-better-named-transition objects which transitions might be allowed.
Gianugo, I'm in no way against having the possibility to easily integrate OSWorkflow or other 3rd party workflow engines.
However I believe the complexity of the workflow I described in another email is >= 80% of all workflow requirements. If I can come up with a solution (and believe me, I'm wide open to suggestions for improvement or alternatives) within 3 days, I prefer that. What I want is simple solutions to simple problems.
I just couldn't find out how to use OSWorkflow within 2 hours so I moved on. Anything else would have been beyond my budget and my scope.
Did you follow Tim Bray's blog ranting about TPSM (Technology Predictor Success Matrix)? http://www.tbray.org/ongoing/What/Technology/Prediction/ He examined 11 candidate predictors (potential success factors for a new technology). The winner of this 11 candidate predictors was the 80/20 point (being able to come up with 80% of functionality with 20% effort).
:-)
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.
... which is exactly the point of user-defined workflows.
I don't need user-defined workflows and I didn't want to suggest to adapt my approach (just wanting to provide input) but FWIW if you change getAllowedXY(doc user) to getAllowed(state, doc, user)
it at least _appears_ to be more reusable :-)
But again, the major point is connecting the states together, and you would have to specify it somehow when adding new states or changing the workflow and I doubt this really is easier to do with a XML syntax.
Guido
--
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
-------------------------------------------------
