cocoon-dev mailing list archives

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

<snip/>

> > 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!



Mime
View raw message