Workflow::Action man page on Fedora

Man page or keyword search:  
man Server   31170 pages
apropos Keyword Search (all sections)
Output format
Fedora logo
[printable version]

Workflow::Action(3)   User Contributed Perl Documentation  Workflow::Action(3)

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.

OBJECT METHODS
   Public Methods
       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.

   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.

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>

perl v5.14.1			  2011-07-21		   Workflow::Action(3)
[top]

List of man pages available for Fedora

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net