On Thu, Jan 27, 2011 at 06:02:02PM -0800, Raphael Simon wrote:
>
> > I guess the launch call would immediately fail. Patrice, in that thread,
> > really wants the process >to fail immediately (not asynchronously).
> >
> > What is your take ?
>
> That makes sense to me, at some level this would be an error in the workflow
> definition itself rather than an error in the execution so the earlier the
> failure the better.
Hello Raphael,
In that case, the check_and_launch approach I describe is handy, but it's not
applicable to subprocesses.
> > Via a participant is right.
> > What happens when the expected fields are not here ? Error ?
>
> Yes, it's a contract violation.
OK.
> The filtering mechanism you describe could help 'reuse' the contract
> definitions for multiple sub-processes but we would want the definition to
> be explicit in the workflow rather than embedded in a participant.
what should it look like ?
---8<---
define 'x' do
signature do
server_id :required => true, :type => String
#...
end
# body...
end
--->8---
?
> The filtering would give some of the scoping too. I'm wondering: where would
> the fields "filtered out" be stored so that they can be merged back after the
> participant replies?
Each expression stores the workitem ('applied_workitem' field) upon getting
applied, so the storage already occurs.
So we have filters and signatures... Filters have a scope, signatures behave
more like checkpoints.
I think I'd like to implement the filter feature. The signature one needs
refining.
Cheers,
--
John Mettraux - http://jmettraux.wordpress.com
--
you received this message because you are subscribed to the "ruote users" group.
to post : send email to [email protected]
to unsubscribe : send email to [email protected]
more options : http://groups.google.com/group/openwferu-users?hl=en
