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?
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.
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
-------------------------------------------------
