Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 54542 invoked from network); 19 Nov 2001 05:11:20 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 19 Nov 2001 05:11:20 -0000 Received: (qmail 2507 invoked by uid 97); 19 Nov 2001 05:11:28 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 2391 invoked by uid 97); 19 Nov 2001 05:11:27 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 2282 invoked by uid 97); 19 Nov 2001 05:11:26 -0000 Date: 19 Nov 2001 04:56:49 -0000 Message-ID: <20011119045649.17601.qmail@icarus.apache.org> From: craigmcc@apache.org To: jakarta-commons-sandbox-cvs@apache.org Subject: cvs commit: jakarta-commons-sandbox/workflow/src/java/org/apache/commons/workflow/core package.html X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N craigmcc 01/11/18 20:56:49 Modified: workflow/src/java/org/apache/commons/workflow/core package.html Log: Document a few more Step executions. Revision Changes Path 1.3 +138 -3 jakarta-commons-sandbox/workflow/src/java/org/apache/commons/workflow/core/package.html Index: package.html =================================================================== RCS file: /home/cvs/jakarta-commons-sandbox/workflow/src/java/org/apache/commons/workflow/core/package.html,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- package.html 2001/11/18 23:38:51 1.2 +++ package.html 2001/11/19 04:56:49 1.3 @@ -90,8 +90,28 @@ <core:goto step="notOk"> +

core:call

+

The core:call Step pops the top value from the evaluation stack, +which must be an Activity, and initiates a +"subroutine call" to execute this Activity before resuming the current one. +Control will be returned to the step following this one, once the called +Activity executes an core:exit Step, or the last +defined Step in the Activity has been executed.

+ +

In the example below, the activity property of the +process bean is assumed to return an instance of Activity that +is to be executed to accomplish a portion of a business process. This allows +components to manage the overall control flow dynamically.

+
  +  <core:get>
  +    <core:descriptor xpath="process/activity"/>
  +  </core:get>
  +  <core:call>
  +
+ +

construct

duplicate

@@ -105,12 +125,90 @@

invoke

load

+ + +

core:notAnd

+ +

The core:notAnd Step evaluates the properties specified by all +nested <core:descriptor> elements, and transfers control +to the specified step if ALL of them are false (if boolean) or +null (if Object). To avoid non-deterministic evaluation stack behavior, all of +the nested <core:descriptor> elements are always evaluated.

+ +

NOTE: - This is the exact opposite of +and.

+ +

The core:notAnd element recognizes the following attributes: +

    +
  • id - Optional identifier of this Step, which can be used + as the destination for control transfers. If specified, must be unique + within the current Activity.
    • +
  • step - Identifier of the Step (within this Activity) to + which control should be transferred if the condition is met.
    • +
+ +

You may nest any number of core:descriptor +elements within a core:notAnd element. All of them will be evaluated +in order to determine whether or not a branch to the Step specified by the +step attribute should occur or not.

+ +

In the following example, control will branch to the Step labelled +empty if all of the specified properties of the +address bean return null String values. Otherwise, control will +be transferred (via the core:goto Step) to the Step labelled +notEmpty.

+
  +  <core:notAnd step="empty">
  +    <core:descriptor xpath="address/street1"/>
  +    <core:descriptor xpath="address/city"/>
  +    <core:descriptor xpath="address/state"/>
  +    <core:descriptor xpath="address/zipCode"/>
  +  </core:and>
  +  <core:goto step="notEmpty">
  +
+ + +

core:notOr

-

notAnd

+

The core:notOr Step evaluates the properties specified by all +nested <core:descriptor> elements, and transfers control +to the specified step if ANY of them are false (if boolean) or +null (if Object). To avoid non-deterministic evaluation stack behavior, all of +the nested <core:descriptor> elements are always evaluated.

-

notOr

+

NOTE: - This is the exact opposite of +or.

+

The core:notOr element recognizes the following attributes: +

    +
  • id - Optional identifier of this Step, which can be used + as the destination for control transfers. If specified, must be unique + within the current Activity.
    • +
  • step - Identifier of the Step (within this Activity) to + which control should be transferred if the condition is met.
    • +
+

You may nest any number of core:descriptor +elements within a core:or element. All of them will be evaluated +in order to determine whether or not a branch to the Step specified by the +step attribute should occur or not.

+ +

In the following example, control will branch to the Step labelled +notOk if any of the specified properties of the +address bean return null String values. Otherwise, +control will be transferred (via the core:goto Step) +to the Step labelled ok.

+
  +  <core:and step="notOk">
  +    <core:descriptor xpath="address/street1"/>
  +    <core:descriptor xpath="address/city"/>
  +    <core:descriptor xpath="address/state"/>
  +    <core:descriptor xpath="address/zipCode"/>
  +  </core:and>
  +  <core:goto step="ok">
  +
+ +

core:or

@@ -157,8 +255,45 @@

remove

string

+ + +

core:suspend

-

suspend

+

The core:suspend Step signals our +Context to suspend the execution of the Activity +being processed. The most recent Context.execute() call will +return immediately. On the next call to Context.execute(), +processing will continue with the Step after this one.

+ +

This Step is designed for scenarios where you wish to allow the application +that is managing your workflows to interact with the user before proceeding. +It is especially useful in a web environment, where Activity execution +must be suspended in order to complete the current +HttpServletResponse, and await the next +HttpServletRequest.

+ +

Note - It does not matter how deeply nested you might be in +core:call calls to subordinate Activity executions. +The state of the entire computation is immediately suspended, and will resume +on the next call to Context.execute(), without the calling +application needing to be aware of the nesting.

+ +

In the following example, it is assumed that you are using the Workflow +system in an MVC-style framework, which uses +RequestDispatcher.forward() to pass control to the resource +responsible for creating a particular response. Control will be suspended +until the next request comes in, at which point execution will be resumed. +Thus, a simple multi-page interaction could be scripted like this (in a real +scenario, you would want to deal with "next page" and "previous page" +navigation links as well).

+
  +  <web:forward page="/page-1.jsp"/>
  +  <core:suspend/>
  +  ... process first input request ...
  +  <web:forward page="/page=2.jsp"/>
  +  <core:suspend/>
  +  ... process second input request ...
  +

swap

-- To unsubscribe, e-mail: For additional commands, e-mail: