Hello John,
>what should it look like ?
>
>---8<---
> define 'x' do
> signature do
> server_id :required => true, :type => String
> #...
> end
> # body...
> end
>--->8---
>
>?
Exactly, although I'm hoping it's possible to define a more compact syntax
(this is how my first iteration at FieldsValidationParticipant looked like
and I found it a bit 'heavy' to use).
>Each expression stores the workitem ('applied_workitem' field) upon getting
applied, so the >storage already occurs.
Ah yes that makes sense, then it fits the use case perfectly.
>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.
And the signature can be fully implemented as a participant but the filter
cannot so this makes sense. Thank you for the quick feedback loop, really
appreciate it.
Regarding the filters, would it make sense to also allow defining them
inline, something like:
---8<---
Ruote.process_definition :name => 'my_uber_process' do
sequence do
do_something
a_subprocess :in => [ 'a_field', 'some_other_field', 'orignal_name' =>
'new_name' ],
:out => [ '__result__' => 'new_field' ]
do_something_else
end
end
--->8---
where anything not explicitly listed in the filters list is not given to the
subprocess (in) or merged back into the workitem (out).
I guess if you provide the ability to filter using a participant this could
then be implemented doing something like:
---8<---
mappings :input => ...., :output => ...
a_subprocess :filter => :mappings
--->8---
with the right implementation for the mappings participant. Maybe the former
syntax then just becomes a shortcut for the later.
Thanks again,
--
Raphael.
On Thu, Jan 27, 2011 at 6:15 PM, John Mettraux <[email protected]>wrote:
>
> 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]<openwferu-users%[email protected]>
> more options : http://groups.google.com/group/openwferu-users?hl=en
>
--
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
