Another feature that might be nice to add here is the sense of optional
actions. In this I'm thinking of the standard wizard interface, where
there are three possible directions a user can travel through the
workflow at any time: next, back, finish. If there are 5 actions total,
with only the first three required, then on the first screen only the
next direction would be possible. On the second screen, both next and
back are possible. On the third screen, the finish button finally
becomes active, in addition to next and back. On the fourth screen, all
three are available as well. On the fifth screen, only the finish
direction is appropriate. Some logic to determine which of these
directions is possible would be helpful when building the ui, so as to
know which links are appropriate to make available.
--
J. Daniel Powell
Sr. Systems Architect
Wellogic, Inc.
-----Original Message-----
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 11, 2001 8:13 AM
To: [EMAIL PROTECTED]
Subject: Re: ActionMapping Workflows
OK, so our initial draft working requirements are
1. Define which actions can follow the current action.
2. Define which actions are allowed to be executed immediately before
the current action.
3. Define which action will follow the current action (dynamic action
path).
4. Invoke another workflow and return to the current state when
complete.
I believe the use case tests each of these points.
For what I have in mind, we really need some type of bookmark, like
Martin's ActionRequest. That way the framework can track the prior and
current action request for each session. Then the initial step of a
workflow could cache the prior ActionRequest, and return there when it
is complete.
Each step of the workflow could also cache it's own ActionRequest, to
allow an actor to wander off and then re-enter the workflow again later,
with their data intact.
Forms that rely on a foreign key from another table could also check the
cache to populate those properties. I'm doing this now and it makes
linking related forms very easy.
So, I would envision something like this for the ActionMappings
<!-- This Action would be passed the path to the current workflow,
if any. It would check for any pending ActionRequest (workflow
already begun) and forward to that instead of "next" if present -->
<action
path="/workflow/registration"
type="bbs.workflow.init"
validate="false"
parameter="registration">
<forward
name="next"
path="/workflow/registration/account/Input"
/>
</action>
<action
path="/workflow/registration/account/Input"
type="bbs.account.http.Access"
name="accountForm"
validate="false"
workflow="registration"
parameter="input">
<!-- Before forwarding to "next" each action would
set an ActionRequest record to itself when workflow!=null -->
<forward
name="next"
path="/WEB-INF/pages/account/Form.jsp"
submit="/workflow/registration/account/Insert"
/>
<forward
name="cancel"
path="/workflow/registeration/Release"
/>
</action>
<action
path="/workflow/registration/account/Insert"
type="bbs.account.http.Access"
name="contactForm"
validate="true"
input="/WEB-INF/pages/account/Form.jsp"
workflow="registration"
parameter="insert">
<forward
name="back"
path="/workflow/registration/account/Input"
/>
<forward
name="next"
path="/workflow/registration/contact/Input"
/>
<forward
name="cancel"
path="/workflow/registeration/Release"
/>
</action>
<action
path="/workflow/registration/contact/Input"
type="bbs.contact.http.Access"
name="contactForm"
validate="false"
workflow="registration"
parameter="input">
<forward
name="next"
path="/WEB-INF/pages/contact/Form.jsp"
submit="/workflow/registration/contact/Insert"
/>
<forward
name="cancel"
path="/workflow/registeration/Release"
/>
</action>
<action
path="/workflow/registration/contact/Insert"
type="bbs.contact.http.Access"
name="contactForm"
validate="true"
input="/WEB-INF/pages/contact/Form.jsp"
workflow="registration"
parameter="insert">
<forward
name="back"
path="/workflow/registration/contact/Input"
/>
<forward
name="next"
path="/workflow/registration/Validate"
/>
<forward
name="cancel"
path="/workflow/registeration/Release"
/>
</action>
<!-- This Action would review the steps of the workflow and
make sure everything was complete, and make any additional
updates needed to reflect that the workflow was successful.
-->
<action
path="/workflow/registration/Validate"
type="bbs.workflow.registration.validate"
validate="false"
workflow="registration" >
<forward
name="back"
path="/workflow/registration/"
/>
<forward
name="next"
path="/workflow/registration/Release"
/>
</action>
<!-- This Action would release any cached data. If another workflow was
registered at the beginning, it would forward there instead of the given
next -->
<action
path="/workflow/registration/Release"
type="bbs.workflow.release"
validate="false"
workflow="registration"
parameter="/workflow/registration/*" >
<forward
name="next"
path="/menu"
/>
<forward
name="prev"
path="/workflow/Invalid"
parameter="/workflow/registration"
/>
</action>
<!-- /workflow/Invalid would be a generic error page that would return
the Action to the beginning of the workflow to enter missing data -->
Matthias Bauer wrote:
>
> First of all: Sounds good to restate the requirement.
>
> Second: Maybe we can talk of some use cases here, in order to put some
flesh to
> the workflow bones.
>
> How about considering the following really simple use case:
>
> Workflow1: The user browses in an open community board and is
currently visiting
> Board xy and Thread yz. Now he wants to add a new comment to the
thread. He
> needs a valid account for that. As he does not yet have an account, he
decides
> to register himself. He ends up in starting Workflow2.
>
> Workflow2: The user steps through the registration process, entering
his
> personal data and his desired username and password.
>
> After Workflow2 has been finished he needs to return to Workflow1, i.
e exactly
> to the same position (Board xy and Thread yz) where he came from.
>
> I don't know if this use case is appropriate. If not, pls come up with
a better
> or extended one. It surely is too trivial to cover all the aspects,
but maybe it
> helps to clarify at least the basic streamlines.
>
> How do you all think the chain of action mappings should look like for
this use
> case and what happens regarding to the stack everybody talks of?
>
> --- Matthias
