Workflow::Condition(3)User Contributed Perl DocumentatioWorkflow::Condition(3)NAMEWorkflow::Condition - Evaluate a condition depending on the workflow
state and environment
VERSION
This documentation describes version 1.07 of this package
SYNOPSIS
# First declare the condition in a 'workflow_condition.xml'...
<conditions>
<condition
name="IsAdminUser"
class="MyApp::Condition::IsAdminUser">
<param name="admin_group_id" value="5" />
<param name="admin_group_id" value="6" />
</condition>
...
# Reference the condition in an action of the state/workflow definition...
<workflow>
<state>
...
<action name="SomeAdminAction">
...
<condition name="IsAdminUser" />
</action>
<action name="AnotherAdminAction">
...
<condition name="IsAdminUser" />
</action>
<action name="AUserAction">
...
<condition name="!IsAdminUser" />
</action>
</state>
...
</workflow>
# Then implement the condition
package MyApp::Condition::IsAdminUser;
use strict;
use base qw( Workflow::Condition );
use Workflow::Exception qw( condition_error configuration_error );
__PACKAGE__->mk_accessors( 'admin_group_id' );
sub _init {
my ( $self, $params ) = @_;
unless ( $params->{admin_group_id} ) {
configuration_error
"You must define one or more values for 'admin_group_id' in ",
"declaration of condition ", $self->name;
}
my @admin_ids = $self->_normalize_array( $params->{admin_group_id} );
$self->admin_group_id( { map { $_ => 1 } @admin_ids } );
}
sub evaluate {
my ( $self, $wf ) = @_;
my $admin_ids = $self->admin_group_id;
my $current_user = $wf->context->param( 'current_user' );
unless ( $current_user ) {
condition_error "No user defined, cannot check groups";
}
foreach my $group ( @{ $current_user->get_groups } ) {
return if ( $admin_ids->{ $group->id } );
}
condition_error "Not member of any Admin groups";
}
DESCRIPTION
Conditions are used by the workflow to see whether actions are
available in a particular context. So if user A asks the workflow for
the available actions she might get a different answer than user B
since they determine separate contexts.
NOTE: The condition is enforced by Workflow::State. This means that the
condition name must be visible inside of the state definition. If you
specify the reference to the condition only inside of the full action
specification in a seperate file then nothing will happen. The
reference to the condition must be defined inside of the state/workflow
specification.
CONFIGURATION
While some conditions apply to all workflows, you may have a case where
a condition has different implementations for different workflow types.
For example, IsAdminUser may look in two different places for two
different workflow types, but you want to use the same condition name
for both.
You can accomplish this by adding a type in the condition
configuration.
<conditions>
<type>Ticket</type>
<condition
name="IsAdminUser"
class="MyApp::Condition::IsAdminUser">
<param name="admin_group_id" value="5" />
<param name="admin_group_id" value="6" />
</condition>
...
The type must match a loaded workflow type, or the condition won't
work. When the workflow looks for a condition, it will look for a
typed condition first. If it doesn't find one, it will look for non-
typed conditions.
SUBCLASSING
Strategy
The idea behind conditions is that they can be stateless. So when the
Workflow::Factory object reads in the condition configuration it
creates the condition objects and initializes them with whatever
information is passed in.
Then when the condition is evaluated we just call "evaluate()" on the
condition. Hopefully the operation can be done very quickly since the
condition may be called many, many times during a workflow lifecycle --
they are typically used to show users what options they have given the
current state of the workflow for things like menu options. So keep it
short!
Methods
To create your own condition you should implement the following:
init( \%params )
This is optional, but called when the condition is first initialized.
It may contain information you will want to initialize your condition
with in "\%params", which are all the declared parameters in the
condition declartion except for 'class' and 'name'.
You may also do any initialization here -- you can fetch data from the
database and store it in the class or object, whatever you need.
If you do not have sufficient information in "\%params" you should
throw an exception (preferably 'configuration_error' imported from
Workflow::Exception).
evaluate( $workflow )
Determine whether your condition fails by throwing an exception. You
can get the application context information necessary to process your
condition from the $workflow object.
_init
This is a dummy, please refer to "init"
Caching and inverting the result
If in one state, you ask for the same condition again, Workflow uses
the cached result, so that within one list of available actions, you
will get a consistent view. Note that if we would not use caching, this
might not necessary be the case, as something external might change
between the two evaluate() calls.
Caching is also used with an inverted condition, which you can specify
in the definition using "<condition name="!some_condition"">. This
condition returns exactly the opposite of the original one, i.e. if
the original condition fails, this one does not and the other way
round. As caching is used, you can model "yes/no" decisions using this
feature - if you have both "<condition name="some_condition""> and
"<condition name="!some_condition""> in your workflow state definition,
exactly one of them will succeed and one will fail - which is
particularly useful if you use "autorun" a lot.
COPYRIGHT
Copyright (c) 2003-2007 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
Jonas B. Nielsen (jonasbn) <jonasbn@cpan.org> is the current
maintainer.
Chris Winters <chris@cwinters.com>, original author.
perl v5.14.1 2011-07-21 Workflow::Condition(3)
