Stefano Mazzocchi <[EMAIL PROTECTED]> 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!
