Page History: States
Compare Page Revisions
Page Revision: 2009/10/11 21:39
Overview
Workflow classes can define a set of states allowing a
workflow object to be in one given state. The workflow changes state by excuting 'enterstate' operator. Operations can be performed upon entering and leaving a state. Instance methods and properties can
dynamically change to public or private as the state of the workflow object changes by
using the 'states ' construct.
Defining a State
A state is declared in Jetfire as method with no return type. For example:
public workflow MyFlow
{
// declare a state called 'Start'
Start(){}
}
Entering a State
To enter a state the
'enterstate statename() ' operator needs to be used.
Until the
'enterstate ' operator is excuted the workflow is in a null state.
public workflow MyFlow
{
// 'Start' state
Start()
{
// place code to be executed when
// the state is entered.
}
// constructor
public MyFlow()
{
enterstate Start()
}
}
Using The 'states' Construct
Using the
states construct the access modifier of a method or property can change dynamically as the state of the workflow changes. For example in the following code the method 'Submit' is public when the workflow is in the 'EnterData' state. When the workflow is no longer in the "EnterData" state the 'AddData' method access modifier is private.
private ArrayList dataList = new ArrayList();
//
//method 'AddData' has a dynamic access modifier
//
public void AddData(string data) :states(EnterData)
{
this.dataList.Add(data);
}
| State | AddData |
|---|
| EnterData | public |
| any other state | private |
Examples
This section points to a couple of examples:
- DVD Library
- Request Approval
DVD Library
In this example each DVD in the library is represented by a workflow. The "Borrow" a DVD and "Return" a DVD methods are controlled by the 'states' construct.
Request Approval
This advanced example employs both states and roles in an request approval workflow. The 'state' of workflow ensures once a method is 'approved' that it can not be 'declined' at later date. The
roles determine which users can 'approve' the request.