RE: Re: [OSWF] Status of JIRA WF-198?

I have to say, one of the things that attracted me to OSWF was the
simplicity..  And I think that what Nick is proposing is simpler because it
removes the concept of local versus global actions, and provides a more
compact way of referencing a action over and over.   Also, while what he is
proposing is to solve using the same action over and over, if you have an
action used 3 times, this is a much compactor, simpler way to describe that
as well.

If we change it, lets definitly make sure that the global-actions syntax is
clearly highlighted as deprecated.

Eric

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On
>  Behalf Of
> Nick Dellamaggiore
> Sent: Friday, October 10, 2003 8:47 PM
> To: [email protected]
> Subject: [Opensymphony-developers] Re: [OSWF] Status of JIRA WF-198?
>
>
> Ok. Before I patch, I want to know how global-actions play
> into the new
> "workflow state" semantics of v2.6.  Here is the section that
> worries me:
>
> " If the caller does not explicitly alters the instance
> state, the workflow
> will remain in this state until it is unambigiously completed. This is
> defined to be the case when the workflow cannot possibly
> perform any further
> actions. In this case, the workflow will automatically move
> to the COMPLETED
> state. "
>
> So, once we reach an action with no 'local actions'
> available, the workflow
> is marked completed. Thus, no further actions can be
> performed due to the
> following code in doAction():
>
> if( entry.getState() != WorkflowEntry.ACTIVATED ) {
>    return;
> }
>
> So, the notion of global actions doesn't apply here.  There
> ARE potential
> (global) actions to be fired, but the workflow state
> disallows it since
> there are no local actions left for the current step. Fair enough.
>
> Actually, in a true finite state machine, each state has a
> set of actions
> (as you've correctly modelled). There is no notion of a
> 'global-action'.
> Should we just do away with this feature entirely (in a
> future release)?
> That would be fine by me as long as there was a feature in
> the XML file
> allowing me to refactor a common (not global) action out that
> can then be
> compactly referenced by id in each step it can be used.  At
> runtime, it
> would simply appear as another ActionDescriptor for the Step.  The XML
> notation below would just be shorthand (macro) for writing
> the action out
> over and over again:
>
> <workflow>
>
>    <common-actions>
>       <action id="99" name="Cancel Review">
>          <pre-functions>
>             <!-- ... -->
>          </pre-functions>
>          <results>
>             <unconditional-result old-status   = "Interrupted"
>                                   status       = "Cancelled"
>                                   step         = "100"
>                                   owner        = "${caller}" >
>         <post-functions>
>            <!-- lots of post function definitions I don't
> want to have to
> copy/paste into each action below -->
>         </post-functions>
>        </unconditional-result>
>          </results>
>       </action>
>    </common-actions>
>
>     <step id="10" name="Initial Review"
>             <action id="101" name="Complete Review">
>                <!-- regular action xml goes here -->
>             </action>
>
>            <!-- Workflow Loader code will resolve this action from
> common-actions above since the action body is missing -->
>            <action id="99" />
>
>           <!-- OR give it a special tag to aid in
> parsability/readability -->
>           <common-action id="99" />
>       </step>
> </workflow>
>
>
> I can write the code for this.  I'd leave the current global-action
> semantics intact to allow backward-compatibility and just
> change the Loader
> so it recognized the new shorthard notation.  What do you think?
>
> -nick
>
>
> "Hani Suleiman" <[email protected]> wrote in message
> news:[email protected]...
> > Please do provide a patch, the splits/join stuff is rather
> murky for me
> > and I'd rather someone who is actively using it provide
> patches than be
> > guessing what it's supposed to be doing.
> >
> > On Wednesday, October 8, 2003, at 08:58 PM, Nicholas J.
> Dellamaggiore
> > wrote:
> >
> > > I posted a JIRA about 2 months ago regarding a pretty serious
> > > OSWorkflow corruption issue.  In a nutshell, if you're in a split
> > > state (i.e 2 current steps are active) and you fire a
> global action
> > > before the split is resolved, the global action creates
> its new step
> > > and leaves the splits steps alive, thus resulting in THREE current
> > > steps.  The offending code is in AbstractWorkflow
> (actually, I think
> > > all non-getter/setter OSWF code lives here) and I detailed the
> > > potentially buggy areas in the JIRA.  I noticed that the
> JIRA hasn't
> > > been placed into the 2.6 release.  Were you planning to
> fix it for the
> > > upcoming release? If not, I plan to just go ahead and
> patch it myself.
> > >  Thanks.
> > >
> > > http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WF-198
> > >
> > > -nick
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: SF.net Giveback Program.
> > > SourceForge.net hosts over 70,000 Open Source Projects.
> > > See the people who have HELPED US provide better services:
> > > Click here: http://sourceforge.net/supporters.php
> > > _______________________________________________
> > > Opensymphony-developers mailing list
> > > [email protected]
> > >
> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > SourceForge.net hosts over 70,000 Open Source Projects.
> > See the people who have HELPED US provide better services:
> > Click here: http://sourceforge.net/supporters.php
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Opensymphony-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php