Johan Stuyts wrote:Using the GoF State pattern works great for simple state machines and I use it a lot. But the pattern does not talk about nested and/or parallel states, which become incomprehensible when coded in Java; the state machine logic gets intermixed with the document logic.
Johan, can you give me an example of parallel states?
I currently can't even imagine what that might look like on a drawing (hope my business user can ;-) Also I'm not convinced about the need for nested states, although I could think of ways the state pattern might account for that (a state object might use the state pattern itself).
What would be a possible alternative implementation?
The example I gave about newsletters is an example about parallel states. See the attached diagram. You have the usual edit/review/publish cycle for the web part of the document. And in addition you have a test/send cycle for the email part. The email part prevents the sending of the newsletter twice.
The two parts are completely parallel and the total number of possible states of an object is the Cartesian product of all the parallel parts of its state machine. For this example (using four states for the edit/review/publish part) that results in eight possible states.
As for the newsletter problem I'll have to solve that one as well :-)
But I can think of ways to solve that without introducing a whole bunch of new concepts or terminology just to solve that single use case. If you tell me I'm mixing concerns that may be true. I'm fine with mixing concerns and bending the framework a little for complex cases if it's still easy to grasp.
But if the technology doesn't allow me to solve simple problems easily (there might be people claiming the same to be true for Cocoon (in case not being familiar with it) and I think this may be a reason Cocoon not being adopted _much_ wider. I don't mean that as a criticism in any way (it would be one to myself), it's just a fact, AFAICS), I loose interest.
If somebody comes up with a full featured workflow engine still simple to use from Cocoon for simple use cases, I would immediately use that.
A state machine implementation must ofcourse be comprehensible for simple state machines too. To achieve this the implementation must have the following properties:
- easy overview of the whole state machine; you don't have to locate multiple files, or have to jump up and down in a file to understand how things are related;
- be terse; details (with defaults) which are not relevant should not be shown.
I think it is possible to have both these properties.
Guido
-- Johan Stuyts
<<attachment: NewsLetterStateMachine.png>>
