cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: Experience with workflow at Hippo Webworks
Date Mon, 08 Mar 2004 18:25:37 GMT
Stefano Mazzocchi <> writes:


> > In that situation, asking a user to write a new version of 
> a program 
> > for
> > that specific need doesn't seem a good solution to me ;-)
> Wait a second: to you think that guy would be more confortable in 
> writing a FSM code?
> Let's compare apples to apples here: we are not discussing how the 
> workflows should be edited, but how they are going to impact 
> our system 
> and how we are going to build them.
> there are several solution on the table and at least two 
> architecturally 
> orthogonal questions:
>   1) should the workflow engine have direct data control?
>   2) should the workflow engine deal with procedural scripts 
> or finite 
> state machines directly?
> my take would be
>   1) no, it should be saparate, sort of a process knowledge base that 
> the flow logic interrogates when it need to

I would definitely agree.

>   2) procedural scripts: they are always easier to program

Does it really matter if you have 1) ?  At that point I think you're
very close to having a generalized Cocoon component that picks up a work
flow definition and runs with it...  

For the end user I believe you always have to have modeling tools for
building work flow, the internal implementation should be completely
transparent; the first time I wrote GUI modeling tools for work flow was
13 years ago (as a subcontractor for one of the major work flow vendors)
I don't believe the end user expectations have declined since then!

View raw message