/ 
Workflow-1.40
River stage zero No dependents
/ Workflow::Action

NAME

Workflow::Action - Base class for Workflow actions

VERSION

This documentation describes version 1.09 of this package

SYNOPSIS

# Configure the Action...
<action name="CreateUser"
        class="MyApp::Action::CreateUser">
  <field name="username" is_required="yes"/>
  <field name="email" is_required="yes"/>
  <validator name="IsUniqueUser">
      <arg>$username</arg>
  </validator>
  <validator name="IsValidEmail">
      <arg>$email</arg>
  </validator>
</action>

# Define the action

package MyApp::Action::CreateUser;

use base qw( Workflow::Action );
use Workflow::Exception qw( workflow_error );

sub execute {
    my ( $self, $wf ) = @_;
    my $context = $wf->context;

    # Since 'username' and 'email' have already been validated we
    # don't need to check them for uniqueness, well-formedness, etc.

    my $user = eval {
        User->create({ username => $context->param( 'username' ),
                       email    => $context->param( 'email' ) })
    };

    # Wrap all errors returned...

    if ( $@ ) {
        workflow_error
            "Cannot create new user with name '", $context->param( 'username' ), "': $EVAL_ERROR";
    }

    # Set the created user in the context for the application and/or
    # other actions (observers) to use

    $context->param( user => $user );

    # return the username since it might be used elsewhere...
    return $user->username;
}

DESCRIPTION

This is the base class for all Workflow Actions. You do not have to use it as such but it is strongly recommended.

CONFIGURATION

You configure your actions and map them to a specific module in your actions configuration file using the syntax above and that shown in Workflow. In some cases, you'll have actions that apply to all workflows. In more elaborate configurations, you may have one workflow server loading multiple workflows and multiple actions for each. In these cases, you'll have multiple workflow types and you may want actions with the same names to have different behaviors for each type.

For example, you may have a workflow type Ticket and another type Order_Parts. They both may have a Submit action, but you'll want the Submit to be different for each.

You can specify a type in your actions configuration to associate that action with that workflow type. If you don't provide a type, the action is available to all types. For example:

<actions>
  <type>Ticket</type>
  <description>Actions for the Ticket workflow only.</description>
  <action name="TIX_NEW"
         class="TestApp::Action::TicketCreate">
...Addtional configuration...

The type must match an existing workflow type or the action will never be called.

ADDITIONAL ATTRIBUTES

You can validate additional attributes in of your action by doing two things:

  • Set $Workflow::Factory::VALIDATE_ACTION_CONFIG to 1.

  • Provide function validate_config() in your action class.

Then, this function will be called with all the acton attributes when it is parsed. For exmaple, if your action XML looks like this:

<action name="BEGIN" class="My::Class" when="NOW">

You can validate it like this:

  sub My::Class::validate_config {
    my $config = shift;
    unless ('NOW' ne $config->{when}) {
      configuration_error "`$$config{when}' is not a valid value " .
		          "for `when'";
    }
  }

OBJECT METHODS

Public Methods

new()

Subclasses may override this method, but it's not very common. It is called when you invoke a method in your Workflow object that returns an Action object, for example, methods such as $wf->_get_action will call this method.

Your action classes usually subclass directly from Workflow::Action and they don't need to override this method at all. However, under some circumstances, you may find the need to extend your action classes.

Suppose you want to define some extra properties to actions but you also want for some of these properties to depend on a particular state. For example, the action "icon" will almost allways be the same, but the action "index" will depend on state, so you can display your actions in a certain order according to that particular state. Here is an example on how you easily do this by overriding new():

1) Set the less changing properties in your action definition:

<actions>
  <type>foo</type>
  <action name="Browse"
    type="menu_button" icon="list_icon"
    class="actual::action::class">
  </action>

2) Set the state dependant properties in the state definition:

<state name="INITIAL">
  <description>
    Manage Manufaturers
  </description>
  <action index="0" name="Browse" resulting_state="BROWSE">
    <condition name="roleis_oem_mgmt"/>
  </action>
  <action index="1" name="Create" resulting_state="CREATE">
    <condition name="roleis_oem_mgmt"/>
  </action>
  <action index="2" name="Back" resulting_state="CLOSED"/>
</state>

3) Craft a custom action base class

package your::action::base::class;

use warnings;
use strict;

use base qw( Workflow::Action );
use Workflow::Exception qw( workflow_error );

# extra action class properties
my @EXTRA_PROPS = qw( index icon type data );
__PACKAGE__->mk_accessors(@EXTRA_PROPS);

sub new {
  my ($class, $wf, $params) = @_;
  my $self = $class->SUPER::new($wf, $params);
  # set only our extra properties from action class def
  foreach my $prop (@EXTRA_PROPS) {
    next if ( $self->$prop );
    $self->$prop( $params->{$prop} );
  }
  # override specific extra action properties according to state
  my $wf_state = $wf->_get_workflow_state;
  my $action = $wf_state->{_actions}->{$self->name};
  $self->index($action->{index});
  return $self;
}


1;

Note: this hack takes advantage of the fact that the XML parser picks up the extra parameters and add them to the action hash of the current $wf_state. Your milage may vary.

4) Use your custom action base class instead of the default

package actual::action::class;

use warnings;
use strict;

use base qw( your::base::action::class );
use Workflow::Exception qw( workflow_error );

sub execute {
  ...
}

1;

Private Methods

init( $workflow, \%params )

init is called in conjuction with the overall workflow initialization.

It sets up the necessary validators based on the on configured actions, input fields and required fields.

add_field( @fields )

Add one or more Workflow::Action::InputFields to the action.

required_fields()

Return a list of Workflow::Action::InputField objects that are required.

optional_fields()

Return a list of Workflow::Action::InputField objects that are optional.

fields()

Return a list of all Workflow::Action::InputField objects associated with this action.

add_validators( @validator_config )

Given the 'validator' configuration declarations in the action configuration, ask the Workflow::Factory for the Workflow::Validator object associated with each name and store that along with the arguments to be used, runtime and otherwise.

get_validators()

Get a list of all the validator hashrefs, each with two keys: 'validator' and 'args'. The 'validator' key contains the appropriate Workflow::Validator object, while 'args' contains an arrayref of arguments to pass to the validator, some of which may need to be evaluated at runtime.

validate( $workflow )

Run through all validators for this action. If any fail they will throw a Workflow::Exception, the validation subclass.

execute( $workflow )

Subclasses must implement -- this will perform the actual work. It's not required that you return anything, but if the action may be used in a Workflow::State object that has multiple resulting states you should return a simple scalar for a return value.

add_fields

Method to add fields to the workflow. The method takes an array of fields.

SEE ALSO

Workflow

Workflow::Factory

COPYRIGHT

Copyright (c) 2003-2004 Chris Winters. All rights reserved.

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

AUTHORS

Chris Winters <chris@cwinters.com>