Workflow 0.10

on Perl CPAN

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:

   <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.