Hunsberger, Peter wrote:
Hmm, not sure. Work flow has been around well over 10 years and pretty
well defined for all that time.
That may be true for the term in general (although I'm not so sure about
it as almost each time I hear somebody mentioning that term it's in a
different context and I
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
However, on the
Cocoon side it's not the GUI I'm worried about, it's the underlying
engine. There may still be value in one of the other
projects,
Hunsberger, Peter wrote:
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
However, on the
Cocoon side it's not the GUI I'm worried about, it's the underlying
engine. There may still be value in one of the
Guido Casper [EMAIL PROTECTED] writes:
snip /
Do you think you can encapsulate that behind an interface
like this? -setState(doc, requestedState, user, optionalObject)
-getState(doc)
-getAllowedActions(doc, user)
I was trying to figure that out myself. I guess the main
Hunsberger, Peter wrote:
AFAICS JDO and XQuery _have_ been created bottom up (the same
is true for JDBC). Neither would be there without 20 years of
SQL (and other
database) experience (and the way JDO was born was eagerly
debated - to say the least). I don't think JDO fits each and
every
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
snip/
I guess this depends on your definition of bottom up? The
way I was
understanding you was more along the lines as an
incremental approach
starting very small. Although JDBC has definitely been built
Hunsberger, Peter wrote:
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
However, on the
Cocoon side it's not the GUI I'm worried about, it's the underlying
engine. There may still be value in one of the other
projects, but I'm
personally after very tight integration with
On Tue, 9 Mar 2004 14:35:42 -0600, Hunsberger, Peter
[EMAIL PROTECTED] wrote:
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
You can call it whatever you want but a state in a FSM and a
continuation in a script are exactly the same thing, they need to
contain the same amount of
Hunsberger, Peter wrote:
Well I probably don't need to repeat my biases to Stephano, but once
more: you need a Turing complete language to write work flow in. You
need to be able to dynamically modify any given work flow instance.
FSM's can't do this, perhaps some other forms of state machines
Stefano Mazzocchi [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
Well I probably don't need to repeat my biases to Stephano, but once
more: you need a Turing complete language to write work
flow in. You
need to be able to dynamically modify any given work flow instance.
FSM's
On Mon, 08 Mar 2004 19:58:32 +0100, Guido Casper [EMAIL PROTECTED]
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
On Sun, 07 Mar 2004 18:06:17 -0500, Stefano Mazzocchi [EMAIL PROTECTED]
wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Guido Casper wrote:
Stefano Mazzocchi wrote:
If FSM work bad for flow, why would they work any better for
workflow?
After thinking again about ways to use
On Mon, 8 Mar 2004 15:49:31 -0600, Hunsberger, Peter
[EMAIL PROTECTED] wrote:
snip
I think it would be a good idea to talk about these two
-a user-oriented workflow tool with a modeling UI and a well defined
limited context
-and a more flexible development tool
as separate implementations
Johan Stuyts wrote:
On Sun, 07 Mar 2004 18:06:17 -0500, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Guido Casper wrote:
Stefano Mazzocchi wrote:
If FSM work bad for flow, why would they work any better for
workflow?
After thinking again
Johan Stuyts wrote:
On Mon, 8 Mar 2004 15:49:31 -0600, Hunsberger, Peter
[EMAIL PROTECTED] wrote:
snip
I think it would be a good idea to talk about these two
-a user-oriented workflow tool with a modeling UI and a well defined
limited context
-and a more flexible development tool
as separate
Stefano Mazzocchi [EMAIL PROTECTED] writes:
snip/
This won't be easy in state machines either, but I think it
is possible
if you store state paths. When the workflow instance is
read by a new
workflow definition, the definition matches the paths to his states.
You can call it
Hunsberger, Peter wrote:
A good implementation of work flow handling for Cocoon could be the most
important piece of missing capability that can be added. For the most
part good work flow engines are expensive proprietary pieces of
software. If a generalized, open source, document handling
Hunsberger, Peter wrote:
You can call it whatever you want but a state in a FSM and a
continuation in a script are exactly the same thing, they need to
contain the same amount of data to be able to resort the execution.
The problems in replicating one across containers will be the same
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
A good implementation of work flow handling for Cocoon could be the
most important piece of missing capability that can be
added. For the
most part good work flow engines are expensive proprietary
pieces of
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
You can call it whatever you want but a state in a FSM and a
continuation in a script are exactly the same thing, they need to
contain the same amount of data to be able to resort the execution.
The problems in replicating
Hunsberger, Peter wrote:
However, on the
Cocoon side it's not the GUI I'm worried about, it's the underlying
engine. There may still be value in one of the other projects, but I'm
personally after very tight integration with Cocoon flow...
Ah, OK, I'm still not getting how that might work :-)
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
However, on the
Cocoon side it's not the GUI I'm worried about, it's the underlying
engine. There may still be value in one of the other
projects, but I'm
personally after very tight integration with Cocoon flow...
Gianugo Rabellino wrote:
Guido Casper wrote:
Gianugo Rabellino wrote:
workflow-manager
state name=tobeprocessed class=TobeprocessedState
entering-action class=TobeprocessedAction/
/state
state name=beingprocessed class=BeingprocessedState
entering-action class=BeingprocessedAction/
On Sun, 07 Mar 2004 21:47:26 +0100, Gianugo Rabellino [EMAIL PROTECTED]
wrote:
Guido Casper wrote:
Gianugo Rabellino wrote:
For one, this might buy usage of some well-established worflow
description languages, such as XPDL or BPEL: this would mean, in turn,
being able to use existing tools to
Johan Stuyts wrote:
On Fri, 05 Mar 2004 17:18:53 -0500, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Johan Stuyts wrote:
Experience with workflow at Hippo Webworks
==
At Hippo we used OSWorkflow to implement a workflow solution in a demo.
Below are our
On Mon, 08 Mar 2004 11:41:12 +0100, Unico Hommes [EMAIL PROTECTED] wrote:
Johan Stuyts wrote:
On Fri, 05 Mar 2004 17:18:53 -0500, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Johan Stuyts wrote:
Experience with workflow at Hippo Webworks
==
At Hippo we
Guido Casper [EMAIL PROTECTED] writes:
Continuations within a webapps are better than a FSMs because
the FSM approach is just a workaround for the lack of a
single-threaded view of my webapp and continuations brought
back that view to me. However for potentially everlasting
conditional
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
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,
Hunsberger, Peter wrote:
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
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
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
Hunsberger, Peter wrote:
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
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
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
For the end user I believe you always have to have modeling
tools for
building work flow, the internal implementation should be
completely
Stefano Mazzocchi wrote:
Guido Casper wrote:
Stefano Mazzocchi wrote:
If FSM work bad for flow, why would they work any better for workflow?
After thinking again about ways to use continuations with workflow I
came to the conclusion this might well be possible. But it looks awkward
to me.
Stefano Mazzocchi wrote:
Guido Casper wrote:
Stefano Mazzocchi wrote:
If FSM work bad for flow, why would they work any better for workflow?
After thinking again about ways to use continuations with workflow I
came to the conclusion this might well be possible. But it looks awkward
to me.
Guido Casper wrote:
Interesting. would you like to share that with us? I think it would be
avery good exercise to see the two approaches one beside the other.
I don't have interest in generating my complete workflow logic out of a
UML diagramm or a XML file. I remember there have been
Guido Casper wrote:
Johan,
thanks a lot for sharing your experiences.
As it happens I'm right now implementing workflow for a customer.
I have no knowledge about OSWorkflow (or any other commercial or
non-commercial workflow engine) and having looked at Lenya's workflow
package I couldn't
Stefano Mazzocchi wrote:
Guido Casper wrote:
Stefano Mazzocchi wrote:
If FSM work bad for flow, why would they work any better for workflow?
After thinking again about ways to use continuations with workflow I
came to the conclusion this might well be possible. But it looks awkward
to me.
Gianugo Rabellino wrote:
Guido Casper wrote:
Interesting. would you like to share that with us? I think it would
be avery good exercise to see the two approaches one beside the other.
I don't have interest in generating my complete workflow logic out of
a UML diagramm or a XML file. I
Guido Casper wrote:
The major drawback currently is that my AbstractState has to know
about all the other states (to prevent each State class having to
know about all the other states) and (when adding NewState) has to be
updated with: allowEnterNewState(doc, user) {return false;}
I have the
Guido Casper wrote:
Gianugo Rabellino wrote:
For one, this might buy usage of some well-established worflow
description languages, such as XPDL or BPEL: this would mean, in turn,
being able to use existing tools to manage the workflow configuration.
This is a very important point IMO: workflow
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Guido Casper wrote:
Stefano Mazzocchi wrote:
If FSM work bad for flow, why would they work any better for workflow?
After thinking again about ways to use continuations with workflow I
came to the conclusion this might well be possible. But it
-
Johan Stuyts wrote:
Experience with workflow at Hippo Webworks
==
At Hippo we used OSWorkflow to implement a workflow solution in a demo.
Below are our experiences.
As people with different levels of experience are interested in workflow
I will start
Stefano Mazzocchi wrote:
Johan Stuyts wrote:
Experience with workflow at Hippo Webworks
==
At Hippo we used OSWorkflow to implement a workflow solution in a
demo. Below are our experiences.
As people with different levels of experience are interested
Guido Casper wrote:
Stefano Mazzocchi wrote:
If FSM work bad for flow, why would they work any better for workflow?
After thinking again about ways to use continuations with workflow I
came to the conclusion this might well be possible. But it looks awkward
to me.
Each document attached to
Experience with workflow at Hippo Webworks
==
At Hippo we used OSWorkflow to implement a workflow solution in a demo.
Below are our experiences.
As people with different levels of experience are interested in workflow I
will start with a (very) brief
Johan Stuyts wrote:
Experience with workflow at Hippo Webworks
==
At Hippo we used OSWorkflow to implement a workflow solution in a demo.
Below are our experiences.
As people with different levels of experience are interested in workflow
I will start
47 matches
Mail list logo
