cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Stuyts <jo...@hippo.nl>
Subject Re: Experience with workflow at Hippo Webworks
Date Tue, 09 Mar 2004 10:22:30 GMT
On Mon, 08 Mar 2004 19:58:32 +0100, Guido Casper <gcasper@s-und-n.de> 
wrote:

> 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
Mime
View raw message