|
NAMEWorkflow::Action - Base class for Workflow actionsVERSIONThis documentation describes version 1.60 of this packageSYNOPSIS# 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; } DESCRIPTIONThis is the base class for all Workflow Actions. You do not have to use it as such but it is strongly recommended.CONFIGURATIONYou 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. STANDARD ATTRIBUTESEach action supports the following attributes:
These attributes (except for the "class" attribute) all map to instance properties by the same name. ADDITIONAL ATTRIBUTESYou can validate additional attributes in of your action by doing two things:
Then, this function will be called with all the acton attributes when it is parsed. For example, 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' eq $config->{when}) { configuration_error "`$$config{when}' is not a valid value " . "for `when'"; } } OBJECT METHODSPublic Methodsnew()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. init() 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 init { my ($self, $wf, $params) = @_; $self->SUPER::init($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}); } 1; 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; 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. Private Methodsinit( $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. 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
COPYRIGHTCopyright (c) 2003-2022 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. Please see the LICENSE AUTHORSPlease see Workflow
Visit the GSP FreeBSD Man Page Interface. |