Thanks for pointing to the undo/redo expressions, they seem very useful. My
initial idea was that if you wanted inner sequence to return as soon as a
child returns an error then they should also be 'try_sequence'. a 'sequence'
inside a 'try_sequence' would run entirely even if a child expression
returned an error (and that can be potentially useful). This means though
that I will need a try_concurrence since I do use concurrence expressions
and I probably want them to abort as soon as a child returns an error.
<try_sequence catch='catch_process' finally='finally_process'>
<sequence>
<participant ref='return_error'/>
<participant ref='will_get_called_anyway'/>
</sequence>
<try_concurrence>
<participant ref='will_get_aborted_if_a_fails'/>
<participant ref='a'/>
<try_sequence>
<participant ref='return_error'/>
<participant ref='wont_get_called'/>
</try_sequence>
</try_concurrence>
<concurrence>
<participant ref='will_finish_even_if_b_returns_an_error'>
<participant ref='b'/>
</concurrence>
</try_sequence>
Note also that 'exceptions' go up the stack, that is if an inner
'try_sequence' expressions also defines a catch subprocess then both that
catch subprocess and any parent catch subprocess will get executed.
This also means that to reuse the current sequence and concurrent
expressions we would need an additional parameter that would identify that
expression as requiring to be aborted as soon as there is an error even
though there is no 'catch' parameter defined.
I seem to prefer this approach to using a else-ref combined with an undo
because I would have to use else-ref on each participant call (and as I
mentioned previously the flows I'm working on involve many participant
calls). With this I only have to specify the catch/finally subprocesses once
and make sure to use try_sequence or try_concurrence appropriately.
--
Raphael.
On Tue, Nov 25, 2008 at 10:07 PM, John Mettraux <[EMAIL PROTECTED]>wrote:
>
> On Wed, Nov 26, 2008 at 2:58 PM, Raphael Simon <[EMAIL PROTECTED]>
> wrote:
> >
> > One way to do this (which is how I was thinking of implementing it) would
> be
> > to introduce a 'try_sequence' which uses a 'catch' and 'finally'
> reference
> > to subprocesses. This expression would inherit from the 'sequence'
> > expression and redefine 'next_child' to replace the next children with
> the
> > 'catch' sub-process if the previously evaluated child returned an error.
> The
> > 'reply' would execute the 'finally' sub-process prior to returning to the
> > parent.
> >
> > <try_sequence catch='catch_process' finally='finally_process'>
> > <participant ref='...'/>
> > <participant ref='...'/>
> > </try_sequence>
> > <process-definition name="catch_process">
> > ...
> > </process-definition>
> > <process-definition name="finally_process">
> > ...
> > </process-definition>
> >
> > Two comments:
> >
> > 1. It may also be good to introduce a 'try_concurrence' for completeness
> (I
> > don't have a use case for it right now though)
> > 2. Instead of introducing new expressions, the existing 'sequence' and
> > 'concurrence' expressions could be modified to take these optional
> 'catch'
> > and 'finally' parameters.
> >
> > Does this make sense?
>
> Hello, it makes sense. But the thing that I tried to mention in my
> previous mail was :
>
> <try_sequence>
> <a/>
> <sequence>
> <b0 />
> <b1 />
> </sequence>
> <c/>
> </try_sequence>
>
> The next_child() of the try_sequence is called when transiting from a
> to sequence to c but not when transiting from b0 to b1, it has 1 level
> of depth only.
>
> That's why I was hinting at the undo/redo mecha which could be
> imitated / reused to exit from deep inside a construct.
>
>
> Cheers,
>
> --
> John Mettraux - http://jmettraux.wordpress.com
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OpenWFEru users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/openwferu-users?hl=en
-~----------~----~----~----~------~----~------~--~---
