GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages


Manual Reference Pages  -  CLASS::WORKFLOW::CONTEXT (3)

.ds Aq ’

NAME

Class::Workflow::Context - The context in which a transition is being applied (optional).

CONTENTS

SYNOPSIS



        use Class::Workflow::Context; # or a subclass or something

        my $c = Class::Workflow::Context->new( ... );

        my $new_instance = $transition->apply( $instance, $c );



DESCRIPTION

If you need to pass arbitrary arguments to the workflow, a context object will usually help.

This specific context object provides stash, a writable hash which is essentially free-for-all.

Class::Workflow::Context doesn’t provide much and should generally be subclassed. It is designed to resemble the Catalyst context object.

Usage of a context object is completely optional, and Class::Workflow’s other core objects (Class::Workflow::State, Class::Workflow::Transition, and Class::Workflow::Instance really don’t care about context objects at all).

STYLE GUIDE

When writing a workflow that governs a web application, for example, transitions will generally expect explicit parameters, having to do with their specific responsibility, and more global parameters, like on behalf of which user is this transition being applied.

A context object is a way to provide a standard set of facilities that every transition can expect.



        sub apply {
                my ( $self, $instance, $c, %args ) = @_;

                my $arg = $args{arg_i_care_about};

                my $user = $c->user;

                ...
        }



Conceptually $c is akin to the environment the workflow is being used in, wheras %args are the actual parameters.

Note that this is only one of many possible conventions you can use in your workflow system.

The context should probably not be mutated by the workflow itself. That’s what the workflow instance is for.

CONTEXT ROLES

You are encouraged to create roles for additional paremeters in the context, and compose them together into the final workflow class instead of relying on stash.

This provides a more structured approach, and lets you use lazy_build in the attributes cleanly.

You could also apply runtime roles to the workflow class for a more dynamic and flexible solution.

FIELDS

stash Just a simple hash reference.
Search for    or go to Top of page |  Section 3 |  Main Index


perl v5.20.3 CLASS::WORKFLOW::CONTEXT (3) 2009-05-15

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.