Workflow

Changes for version 0.10

Workflow
- POTENTIAL BACKWARD INCOMPATIBILITY
  - Since we've now got 'resulting_state' in a state's action that is
- dependent on the action results of the previous action being run (see Workflow::State change), we cannot set the 'new' workflow state before executing the action.
  - One result: you shouldn't set the 'state' property of any created
- Workflow::History objects -- we'll modify the state of any history objects with an empty state before saving them (see changes for Workflow::Factory)
  - Another result: the value of '$wf->state' inside your
- Action now refers to the EXISTING state of the workflow not the SOON TO BE state. Earlier versions had the SOON TO BE state set into the workflow before executing the action to make things less confusing. Now that it's changed any code you have using the state of the workflow (such as in our example 'Trouble Ticket' application in eg/ticket/) will give a different value than the previous Workflow version.
  - This behavior seems more consistent, but comments/suggestions
- are welcome.
- In 'execute_action()' -- once we're done executing the main action, check to see if our new state is an autorun state, and if so run it.
Workflow::Action::Null
- New class: use if you want to move the workflow from one state to another without actually doing anything.
Workflow::Condition::Evaluate
- New class: allow inline conditions expressed as Perl code in the 'test' attribution of 'condition'; has access to the values in the current workflow context in a Safe compartment.
Workflow::Factory
- In save_workflow(), call 'set_new_state()' with the workflow state on all unsaved Workflow::History objects before saving them.
Workflow::State
- Add 'autorun' property and 'get_autorun_action_name()' to retrieve the single valid action name available from an autorun state.
- The 'resulting_state' property of an action within a state can now be multivalued, which means the next state depends on the return value of the action that's executed. For instance, we might have:
- <state name="create user"> <action name="create"> <resulting_state return="admin" state="assign as admin" /> <resulting_state return="helpdesk" state="assign as helpdesk" /> <resulting_state return="*" state="assign as luser" /> </action> ....
  - So if the action 'create' returns 'admin', the new state will be
- 'assign as admin'; on 'helpdesk' it will be 'assign as helpdesk', and all other values will go to state 'assign as luser'.
  - Existing behavior (actions returning nothing for a single
- 'resulting_state') is unchanged.

Modules

Workflow - Simple, flexible system to implement workflows
Workflow::Action - Base class for Workflow actions
Workflow::Action::InputField - Metadata about information required by an Action
Workflow::Action::Null
Workflow::Base - Base class with constructor
Workflow::Condition - Evaluate a condition depending on the workflow state and environment
Workflow::Condition::Evaluate - Inline condition that evaluates perl code for truth
Workflow::Condition::HasUser - Condition to determine if a user is available
Workflow::Config - Parse configuration files for the workflow components
Workflow::Config::Perl - Parse workflow configurations as Perl data structures
Workflow::Config::XML - Parse workflow configurations from XML content
Workflow::Context - Data blackboard for Workflows, Actions, Conditions and Validators
Workflow::Exception - Base class for workflow exceptions
Workflow::Factory - Generates new workflow and supporting objects
Workflow::History - Recorded work on a workflow action or workflow itself
Workflow::Persister - Base class for workflow persistence
Workflow::Persister::DBI - Persist workflow and history to DBI database
Workflow::Persister::DBI::AutoGeneratedId - Pull IDs from databases that autogenerate them
Workflow::Persister::DBI::ExtraData - Fetch extra data with each workflow and put it into the context
Workflow::Persister::DBI::SequenceId - Persister to fetch ID from a sequence
Workflow::Persister::File - Persist workflow and history to the filesystem
Workflow::Persister::RandomId - Persister to generate random ID
Workflow::Persister::SPOPS - Persist workflows using SPOPS
Workflow::Persister::UUID - Persister to generate Universally Unique Identifiers
Workflow::State - Information about an individual state in a workflow
Workflow::Validator - Ensure data are valid
Workflow::Validator::HasRequiredField - Validator to ensure certain data are in the context
Workflow::Validator::InEnumeratedType - Ensure a value is one of a declared set of values
Workflow::Validator::MatchesDateFormat - Ensure a stringified date matches a given pattern

	Global
`s`	Focus search bar
`?`	Bring up this help dialog

	GitHub
`g` `p`	Go to pull requests
`g` `i`	go to github issues (only if github is preferred repository)

	POD
`g` `a`	Go to author
`g` `c`	Go to changes
`g` `i`	Go to issues
`g` `d`	Go to dist
`g` `r`	Go to repository/SCM
`g` `s`	Go to source
`g` `b`	Go to file browse

Changes for version 0.10

Modules

Examples

Other files

Changes for version 0.10

Modules

Examples

Other files

Module Install Instructions