perl-workflow-devel — discussion list for developers of Perl Workflow

Re: [Perl-workflow-devel] Log4perl logging and condition evaluation

[Jim B. <cb...@bu...>]

If the main issue is the debug level, maybe you can do something like:

          'log4perl.logger.Workflow.Exception.Condition' => 'DEBUG',

in your log4perl settings?

I didn't test the above specifically, but we have various components in
workflow set to different values in each of our environments (dev, QA,
prod) depending on how chatty we want it to be. It may be more
complicated if they become a workflow error as you said below.

In our configuration, I think we generally don't route people to actions
they shouldn't be performing, so conditions are a backstop rather than a
primary way to manage who can perform which actions.

Andrew O'Brien wrote:
> Hi guys,
> 
> Can someone explain the reasoning behind throwing a workflow_error()
> when conditions evaluate to false? workflow_error() logs at ERROR level.
> 
> 
> Currently, a condition class with an evaluate() method must call
> condition_error() in order to signal that the condition has not been
> met.
> 
> That propagates to a workflow_error() call in
> Workflow::State::evaluate_action() any time that a condition evaluates
> to false. This is caught in Workflow::State::is_action_available() and
> simply used as a boolean.
> 
> This, in turn, fills up logs rather more quickly than I'd like. I just
> can't understand why the simple act of a condition evaluating to false
> (which happens potentially hundreds of times a second and is a perfectly
> normal thing for a condition to do) needs to be promoted to this log
> level.
> 
> You're basically saying that a condition evaluating to false is just one
> level of criticality lower than "FATAL" :)
> 
> As a comparison, a successful condition evaluation is simply logged at
> DEBUG level and no exception is rethrown (I can understand throwing an
> exception, just not one that has the side effect of logging at ERROR
> level)
> 
> Is this just me? Is there some other side effect of this rethrow
> sequence that I'm missing?
> 
> Cheers,
> 
> Andrew
> 
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

-- 
Jim Brandt
Administrative Computing Services
University at Buffalo

[Perl-workflow-devel] Log4perl logging and condition evaluation

[Andrew O'B. <an...@or...>]

Hi guys,

Can someone explain the reasoning behind throwing a workflow_error()
when conditions evaluate to false? workflow_error() logs at ERROR level.


Currently, a condition class with an evaluate() method must call
condition_error() in order to signal that the condition has not been
met.

That propagates to a workflow_error() call in
Workflow::State::evaluate_action() any time that a condition evaluates
to false. This is caught in Workflow::State::is_action_available() and
simply used as a boolean.

This, in turn, fills up logs rather more quickly than I'd like. I just
can't understand why the simple act of a condition evaluating to false
(which happens potentially hundreds of times a second and is a perfectly
normal thing for a condition to do) needs to be promoted to this log
level.

You're basically saying that a condition evaluating to false is just one
level of criticality lower than "FATAL" :)

As a comparison, a successful condition evaluation is simply logged at
DEBUG level and no exception is rethrown (I can understand throwing an
exception, just not one that has the side effect of logging at ERROR
level)

Is this just me? Is there some other side effect of this rethrow
sequence that I'm missing?

Cheers,

Andrew

Re: [Perl-workflow-devel] Updated: Dynamically loaded configs patch (now incl tests)

[Jonas B. N. <jo...@gm...>]

Hi Andrew and others,

Absolutely marvelous. I will evaluate and get back to you (and the list)

Since I will create a branch for the evaluation, you are welcome to  
hack on the branch if you want to, it does however require that you  
are a member on SourceForge (which is free).

Btw. if people would have other preferences as to choice of SCM,  
please let me know. Git is getting a lot of attention from the Perl  
community and in addition github, but also Google Code seems to offer  
a good solution, based on Subversion as the repository we have on  
SourceForge.

Have a nice day,

jonasbn

On 29/01/2009, at 00.41, Andrew O'Brien wrote:

>
> Hi all,
>
> We're just resurrecting some workflow projects here at work and I  
> needed
> this feature so attached is an patch against 1.32. I've also updated  
> the
> original ticket below.
>
> http://rt.cpan.org/Public/Bug/Display.html?id=18265
>
> This patch includes a new dummy workflow and appropriate tests to
> exercise the feature.
>
>
> The original motivation for this feature was that for various  
> reasons we
> weren't able to know all the required workflow config files ahead of
> time for a particular application. At one point we even had external
> dynamically generated files I think.
>
> I guess that if you have large configs or a large set of configs then
> this could be considered a performance feature if you're not going to
> touch much of the config during a given script's execution path. For
> example, we also use this in regularly scheduled jobs that check
> workflows related to the various types of support/project/sales/etc  
> jobs
> in our worklog system.
>
> Any given run of that script might touch three or four types of  
> workflow
> so there's no real point in preloading the 20 or 30 types of workflow
> every single time it executes. Some runs may touch nothing if there  
> has
> been no activity in the system.
>
> Happy to modify based on your feedback.
>
> Cheers,
>
> Andrew
>
> -- 
> Andrew O'Brien
> Development Manager
> e: an...@or...    p: +61 2 9461 0114
> w: www.oriel.com.au        f: +61 2 9431 6700
> < 
> dynamic_configs_1.32 
> .diff 
> > 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

[Perl-workflow-devel] Updated: Dynamically loaded configs patch (now incl tests)

[Andrew O'B. <an...@or...>]

Hi all,

We're just resurrecting some workflow projects here at work and I needed
this feature so attached is an patch against 1.32. I've also updated the
original ticket below.

http://rt.cpan.org/Public/Bug/Display.html?id=18265

This patch includes a new dummy workflow and appropriate tests to
exercise the feature.


The original motivation for this feature was that for various reasons we
weren't able to know all the required workflow config files ahead of
time for a particular application. At one point we even had external
dynamically generated files I think.

I guess that if you have large configs or a large set of configs then
this could be considered a performance feature if you're not going to
touch much of the config during a given script's execution path. For
example, we also use this in regularly scheduled jobs that check
workflows related to the various types of support/project/sales/etc jobs
in our worklog system.

Any given run of that script might touch three or four types of workflow
so there's no real point in preloading the 20 or 30 types of workflow
every single time it executes. Some runs may touch nothing if there has
been no activity in the system.

Happy to modify based on your feedback.

Cheers,

Andrew

-- 
Andrew O'Brien
Development Manager
e: an...@or...    p: +61 2 9461 0114
w: www.oriel.com.au        f: +61 2 9431 6700 

[Perl-workflow-devel] Release 1.32 on CPAN

[Jonas B. N. <jo...@gm...>]

Hello All,

Workflow release 1.32 have made it's way to CPAN.

I will revise the roadmap and post my efforts here (or in the Wiki),  
anyway the information will flow here one for or the other.

Thanks to all contributors and moral supporters and bug reporters,

jonasbn

[Perl-workflow-devel] 0.32_8 tests

[Jonas B. N. <jo...@gm...>]

Hello All.

The tests are passing nicely and we are passing on a broad variety of  
platforms.

	http://bbbike.radzeit.de/~slaven/cpantestersmatrix.cgi?dist=Workflow+0.32_8

Unless anybody are :
- in the process of testing 0.32_8 in their setup
- are of the opinion that we should see more reports come in
- have other reservations or concerns

I will start looking into release 1.32.

jonasbn


--
pauseid: JONASBN
email: jo...@cp...
blog: http://use.perl.org/~jonasbn/journal/

[Perl-workflow-devel] Release 0.32_8

[Jonas B. N. <jo...@gm...>]

Finally!

I got the 0.32_8 release out of the door. Please test and give  
feedback on the list. The Changes file is long and will be cleaned  
before next release, since I aim to boil the work down to the key  
features since last non-beta (0.31) release.. The TODO is long, plenty  
of patch candidates and/or contributions.

Happy Workflowing - I have high ambitions for 2009,

jonasbn
--
pauseid: JONASBN
email: jo...@cp...
blog: http://use.perl.org/~jonasbn/journal/

Re: [Perl-workflow-devel] Next public release? or another beta/dev release

[Jonas B. N. <jo...@gm...>]

Hi Jim,

You are right, I will spend some more time on cleaning up and the POD,  
then I will make a beta release.

Thanks,

jonasbn

On 22/12/2008, at 20.51, Jim Brandt wrote:

>
>
> Jonas Brømsø Nielsen wrote:
>
>> I think a beta more would be appropriate and then I could spend  
>> some  of my time looking into the POD.
>
> Given the number of changes, I think a beta makes sense.
>
> Thanks for all of your work cleaning things up and standardizing.
>
> Jim
>
>
> -- 
> Jim Brandt
> Administrative Computing Services
> University at Buffalo
>

Re: [Perl-workflow-devel] Next public release? or another beta/dev release

[Jim B. <cb...@bu...>]

Jonas Brømsø Nielsen wrote:

> 
> I think a beta more would be appropriate and then I could spend some  
> of my time looking into the POD.
> 

Given the number of changes, I think a beta makes sense.

Thanks for all of your work cleaning things up and standardizing.

Jim


-- 
Jim Brandt
Administrative Computing Services
University at Buffalo

[Perl-workflow-devel] Next public release? or another beta/dev release

[Jonas B. N. <jo...@gm...>]

Hello,

I started to do some minor refactorings based on Perl::Critic feedback  
and I got some more tests implemented.

So this is the current state of the Changes file:

- Removed VERSION file, this has now been obsoleted

- Addressing RT #40750
   http://rt.cpan.org/Ticket/Display.html?id=40750

   We are now resolving the version number for the distribution from  
Workflow.pm
   the main module, this mean a jump from 0.32 to 1.32, but it does  
mean that
   an installation can be traced back to a given distribution

- Added new test file t/workflow_history.t, the new tests of  
Workflow::History
   methods. Added explicit returns so we return a true value when run

- All packages have been run through perltidy addressing the following
   Perl::Critic policies:

   [CodeLayout::ProhibitHardTabs]
   [CodeLayout::ProhibitTrailingWhitespace]
   [CodeLayout::RequireTidyCode]

- Perl::Critic policy [Subroutines::ProhibitExplicitReturnUndef]  
disabled
   this would break APIs at does not seem like a good idea, a more  
thorough
   analysis should however be completed at some point

- Perl::Critic policy [NamingConventions::ProhibitAmbiguousNames]  
disabled
   we have an overwrite of Class::Accessor, which happens to violate  
this policy

- Added use of File::Slurp refactoring a potential problematic body of  
code
   addressing Perl::Critic policy [InputOutput::ProhibitJoinedReadline]
   File::Slurp added to Build.PL

- Some hardcoded numbers have been made into constants, some of these  
are
   candidates however for propagation to a central place. (See TODO  
file)
   This addresses Perl::Critic policy
   [ValuesAndExpressions::ProhibitMagicNumbers] We do however run with  
this
   policy disabled since, it warns about some numbers, which it does  
not make
   sense to refactor into constants. In addition
   [ValuesAndExpressions::ProhibitConstantPragma] is deactivated since  
we
   are using constants

- Added use of warnings pragma, addressing Perl::Critic policy
   [TestingAndDebugging::RequireUseWarnings], I am however not sure  
whether this
   breaks backwards compatibility towards older perls. So this will  
have to be
   investigated (added to TODO file)

- Exchanged calls to die and warn to croak and carp addressing  
Perl::Critic
   policy [ErrorHandling::RequireCarping], this is also considered a  
good module
   practive so errors are perceived from the callers perspective. In  
addition
   Carp was listed in relevant packages and Build.PL

- Added Id keyword to Workflow::Validator::MatchesDateFormat addressing
   Perl::Critic policy [Miscellanea::RequireRcsKeywords]

- Added t/critic.t and t/perlcriticrc getting started on improving code
   quality based on Perl::Critic, the number of contributors are  
increasing and
   Perl::Critic might prove a good tool in assisting in quality  
assurance for
   Workflow in the future

So my question is whether I should push on and release 1.32 or whether  
we should have one more beta/dev release before this, meaning 0.32_8

I got the test coverage up to: 76.8% from 75.3% as mentioned in my  
last mail.

Let me know what you think,

I think a beta more would be appropriate and then I could spend some  
of my time looking into the POD.

If anybody wants to help out with the Perl::Critic addressing, please  
let me know and I will describe the process in detail, it is a bit  
like sudoku, just more rewarding...

jonasbn

Re: [Perl-workflow-devel] Release 0.32_7

[Jonas B. N. <jo...@gm...>]

Hello All,

It seems as if our tests are passing.

http://www.cpantesters.org/show/Workflow.html#Workflow-0.32_7

So unless somebody has anything to object I will merge the  
action_group branch into trunk and I will start looking into making a  
public release.

The overall test coverage doing okay, covering 75.3%, where last  
public release (0.31) had a coverage of 74.3% - after the merge this  
will go down a bit, but nothing significant. Also the documentation  
might need a clean up in spots and some additions. But in general the  
patchers are very good at also adding POD and tests.

So if anybody are interested in obtaining commit rights, please speak  
up. If any of the committers want to contribute in this phase feel  
free to do so.

Commit access to the repository requires a SourceForge account and a  
Subversion client.

Thanks for all the contributions :)


jonasbn

On 17/12/2008, at 15.09, Jonas Brømsø Nielsen wrote:

> Hello All,
>
> I have just uploaded Release 0.32_7 to PAUSE, so it should hit the  
> CPAN mirrors over the next few days.
>
> Feedback and discussion welcome.
>
> jonasbn

[Perl-workflow-devel] Release 0.32_7

[Jonas B. N. <jo...@gm...>]

Hello All,

I have just uploaded Release 0.32_7 to PAUSE, so it should hit the  
CPAN mirrors over the next few days.

Feedback and discussion welcome.

jonasbn

[Perl-workflow-devel] Release 0.32_6 in the green

[Jonas B. N. <jo...@gm...>]

Hello All,

It seems as if the 0.32_6 release is passing it's tests and there have  
been no feedback here, so I am merging the branch into trunk and move  
on with the patches from Ivan.

http://www.cpantesters.org/show/Workflow.html#Workflow-0.32_6

So release 0.32_7 will go out soon.

jonasbn

Re: [Perl-workflow-devel] Workflow patch

[phil r. <phi...@un...>]

Yep, 'group's good.

Cheers, Phil.

Andrew O'Brien wrote:
> Hi Jonas et al,
>
>   
>> Which leads me to group.
>>
>> Any other suggestions, we are talking about actions and logical  
>> grouping (okay that was cheap), of these - what is the best word to  
>> use for this.
>>
>> I vote for group :)
>>     
>
> I agree.
>
> Makes sense to me that we're talking about a logical, arbitrary group name to be (ab)used as the programmer sees fit.
>
> Andrew
>
>   


-- 
+++++++++++++++++++++++++++++++++++++
phi...@un...
Tel: +44 (0)161 257 3532
+++++++++++++++++++++++++++++++++++++

Re: [Perl-workflow-devel] Workflow patch

[Andrew O'B. <an...@or...>]

Hi Jonas et al,

> Which leads me to group.
> 
> Any other suggestions, we are talking about actions and logical  
> grouping (okay that was cheap), of these - what is the best word to  
> use for this.
> 
> I vote for group :)

I agree.

Makes sense to me that we're talking about a logical, arbitrary group name to be (ab)used as the programmer sees fit.

Andrew

Re: [Perl-workflow-devel] Workflow patch

[Jonas B. N. <jo...@gm...>]

Hi Phil and others,

I have pondered over this for a few days and I feel as you do that  
block sounds like stop and in workflow context this might be  
misinterpreted.

As for: type, this word could mean something else, since we are  
programmers and we are building a framework.

Section is good, but I might prefer to use that for a workflow step or  
a section of a workflow.

Which leads me to group.

Any other suggestions, we are talking about actions and logical  
grouping (okay that was cheap), of these - what is the best word to  
use for this.

I vote for group :)


jonasbn

On 12/12/2008, at 13.47, phil robinson wrote:

> Yes, 'block' suggests that it might be something
> to do with 'stop'.
>
> I'd suggest 'section' (if I understand its function
> correctly), but your 'type' or 'group' would also,
> imho, be better than 'block'.
>
> Cheers, Phil.
>
> +++++++++++++++++++++++++++++++++++++
> phi...@un...
> Tel: +44 (0)161 257 3532
> +++++++++++++++++++++++++++++++++++++
>
>
>
> Jonas Brømsø Nielsen wrote:
>> Hola,
>>
>> I have had a look at Ivan's description of the functionality and it
>> seems very useful, not to say powerful.
>>
>> So based on this I will move on with evaluating the actual patches.
>>
>> I only have one issue at this point and that is the word/attribute
>> 'block', I would prefer another name for this.
>>
>> What about: type or group
>>
>> Let me know what you think.
>>
>>
>> jonasbn
>>
>>
>> On 09/12/2008, at 11.06, Jonas Brømsø Nielsen wrote:
>>
>>
>>> Hello All,
>>>
>>> Robert have now been added to our little group of developer - YAY!.
>>>
>>> Which mean that his patch will be added to the branch dedicated for
>>> this. A development release will be made as soon as he gives me a
>>> heads up.
>>>
>>> We have received some additional patches from Ivan Paponov (see
>>> below), who has also joined this list.
>>>
>>> If anybody has the time to evaluate the patches, please feel free.
>>> We can discuss them openly here and I am sure Ivan will be happy to
>>> answer any questions. If a preliminary review of the patches goes
>>> through, I will create a branch for inclusion and test of the  
>>> patches.
>>>
>>> My $work TODO list is getting shorter, so I think I will be able to
>>> dedicate a lot of time over Christmas for Workflow.
>>>
>>>
>>> jonasbn
>>>
>>> Begin forwarded message:
>>>
>>>
>>>> From: Ivan Paponov <iva...@gm...>
>>>> Date: 8. dec 2008 21.59.04 GMT+01:00
>>>> To: jo...@cp...
>>>> Subject: Workflow patch
>>>> Reply-To: Ivan Paponov <iva...@gm...>
>>>>
>>>> Hi Jonas,
>>>>
>>>> My name is Ivan. I'm developing request management system, and the
>>>> base of it is Workflow framework. This module is really flexible  
>>>> and
>>>> powerful, it's really a pleasure to work with it.
>>>>
>>>> But I found one detail that I'm missing in Workflow.
>>>> Here is the situation.
>>>> We created request, and placed it into Submitted state.
>>>> In submitted state we have following actions: terminate, place on
>>>> hold
>>>> and approve.
>>>>
>>>> <action name="terminate"   class="MyApp::Action::Terminate" />
>>>> <action name="place on hold"   class="MyApp::Action::OnHold" />
>>>> <action name="approve request"   class="MyApp::Action::Approve" />
>>>>
>>>> First two should be available on page as simple links, and third is
>>>> approval form, with comment box and approve button. And it's clear
>>>> that
>>>> first two action links have to be placed at the one part of page  
>>>> (in
>>>> header near request title), and approval form at the other.
>>>> Also I want to use $wf->get_current_actions(); function, but how
>>>> should I distinguish where I should place current action, so I
>>>> decided
>>>> to add additional property to the action tag. It's - block.
>>>>
>>>> <action name="terminate"   block="state change"   class="..." />
>>>> <action name="place on hold"   block="state change"    
>>>> class="..." />
>>>> <action name="approve request"   block="approval"   class="..." />
>>>>
>>>> And modified get_current_actions(), so now I can call
>>>> my @actions = $wf->get_current_actions("approval");
>>>> or
>>>> my @actions = $wf->get_current_actions("state change");
>>>> And I get only actions that are members of specified block.
>>>>
>>>> Patches are in the attachments, in case if you'll find this idea
>>>> interesting.
>>>>
>>>> Thank you.
>>>>
>>>> -- Best regards,
>>>> Ivan Paponov
>>>> iva...@gm...
>>>>
>>> <State.pm.diff><Workflow.pm.diff>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,  
>> Nevada.
>> The future of the web can't happen without you.  Join us at MIX09  
>> to help
>> pave the way to the Next Web now. Learn more and register at
>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>> _______________________________________________
>> Perl-workflow-devel mailing list
>> Per...@li...
>> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,  
> Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to  
> help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

Re: [Perl-workflow-devel] Fwd: Workflow patch

[Jonas B. N. <jo...@gm...>]

Hello Robert and all,

I have just merged the changes from release 0.32_5 into your branch  
and have made a release 0.32_6 to CPAN for all of you to evaluate.

Thanks for the effort.

Please let me know if any of you experience any trouble, all tests  
currently pass, so I am keen on feedback from those of you who might  
have the guts to use the release and cover the parts we do not have  
covered with tests just yet.

Of course I will be following the CPAN testers reports closely.

Next step will be the patches from Ivan.


jonasbn


On 15/12/2008, at 17.00, Stockdale, Robert wrote:

> Hello,
>
> I have checked in my changes and some new tests for:
>
>    http://rt.cpan.org/Public/Bug/Display.html?id=38024
>
> -- 
> Bob Stockdale
> Administrative Computing Services
> University at Buffalo
> (716) 645-5334
> rf...@bu...
>
>
>> From: Jonas Brømsø Nielsen <jo...@gm...>
>> Date: Tue, 9 Dec 2008 05:06:12 -0500
>> To: Workflow development list <per...@li...>
>> Subject: [Perl-workflow-devel] Fwd: Workflow patch
>>
>> Hello All,
>>
>> Robert have now been added to our little group of developer - YAY!.
>>
>> Which mean that his patch will be added to the branch dedicated for
>> this. A development release will be made as soon as he gives me a
>> heads up.
>>
>> We have received some additional patches from Ivan Paponov (see
>> below), who has also joined this list.
>>
>> If anybody has the time to evaluate the patches, please feel free. We
>> can discuss them openly here and I am sure Ivan will be happy to
>> answer any questions. If a preliminary review of the patches goes
>> through, I will create a branch for inclusion and test of the  
>> patches.
>>
>> My $work TODO list is getting shorter, so I think I will be able to
>> dedicate a lot of time over Christmas for Workflow.
>>
>>
>> jonasbn
>>
>> Begin forwarded message:
>>
>>> From: Ivan Paponov <iva...@gm...>
>>> Date: 8. dec 2008 21.59.04 GMT+01:00
>>> To: jo...@cp...
>>> Subject: Workflow patch
>>> Reply-To: Ivan Paponov <iva...@gm...>
>>>
>>> Hi Jonas,
>>>
>>> My name is Ivan. I'm developing request management system, and the
>>> base of it is Workflow framework. This module is really flexible and
>>> powerful, it's really a pleasure to work with it.
>>>
>>> But I found one detail that I'm missing in Workflow.
>>> Here is the situation.
>>> We created request, and placed it into Submitted state.
>>> In submitted state we have following actions: terminate, place on  
>>> hold
>>> and approve.
>>>
>>> <action name="terminate"   class="MyApp::Action::Terminate" />
>>> <action name="place on hold"   class="MyApp::Action::OnHold" />
>>> <action name="approve request"   class="MyApp::Action::Approve" />
>>>
>>> First two should be available on page as simple links, and third is
>>> approval form, with comment box and approve button. And it's clear
>>> that
>>> first two action links have to be placed at the one part of page (in
>>> header near request title), and approval form at the other.
>>> Also I want to use $wf->get_current_actions(); function, but how
>>> should I distinguish where I should place current action, so I  
>>> decided
>>> to add additional property to the action tag. It's - block.
>>>
>>> <action name="terminate"   block="state change"   class="..." />
>>> <action name="place on hold"   block="state change"   class="..." />
>>> <action name="approve request"   block="approval"   class="..." />
>>>
>>> And modified get_current_actions(), so now I can call
>>> my @actions = $wf->get_current_actions("approval");
>>> or
>>> my @actions = $wf->get_current_actions("state change");
>>> And I get only actions that are members of specified block.
>>>
>>> Patches are in the attachments, in case if you'll find this idea
>>> interesting.
>>>
>>> Thank you.
>>>
>>> -- 
>>> Best regards,
>>> Ivan Paponov
>>> iva...@gm...
>

Re: [Perl-workflow-devel] Fwd: Workflow patch

[Stockdale, R. <rf...@bu...>]

Hello,

I have checked in my changes and some new tests for:

    http://rt.cpan.org/Public/Bug/Display.html?id=38024

-- 
Bob Stockdale
Administrative Computing Services
University at Buffalo
(716) 645-5334
rf...@bu...


> From: Jonas Brømsø Nielsen <jo...@gm...>
> Date: Tue, 9 Dec 2008 05:06:12 -0500
> To: Workflow development list <per...@li...>
> Subject: [Perl-workflow-devel] Fwd: Workflow patch
> 
> Hello All,
> 
> Robert have now been added to our little group of developer - YAY!.
> 
> Which mean that his patch will be added to the branch dedicated for
> this. A development release will be made as soon as he gives me a
> heads up.
> 
> We have received some additional patches from Ivan Paponov (see
> below), who has also joined this list.
> 
> If anybody has the time to evaluate the patches, please feel free. We
> can discuss them openly here and I am sure Ivan will be happy to
> answer any questions. If a preliminary review of the patches goes
> through, I will create a branch for inclusion and test of the patches.
> 
> My $work TODO list is getting shorter, so I think I will be able to
> dedicate a lot of time over Christmas for Workflow.
> 
> 
> jonasbn
> 
> Begin forwarded message:
> 
>> From: Ivan Paponov <iva...@gm...>
>> Date: 8. dec 2008 21.59.04 GMT+01:00
>> To: jo...@cp...
>> Subject: Workflow patch
>> Reply-To: Ivan Paponov <iva...@gm...>
>> 
>> Hi Jonas,
>> 
>> My name is Ivan. I'm developing request management system, and the
>> base of it is Workflow framework. This module is really flexible and
>> powerful, it's really a pleasure to work with it.
>> 
>> But I found one detail that I'm missing in Workflow.
>> Here is the situation.
>> We created request, and placed it into Submitted state.
>> In submitted state we have following actions: terminate, place on hold
>> and approve.
>> 
>> <action name="terminate"   class="MyApp::Action::Terminate" />
>> <action name="place on hold"   class="MyApp::Action::OnHold" />
>> <action name="approve request"   class="MyApp::Action::Approve" />
>> 
>> First two should be available on page as simple links, and third is
>> approval form, with comment box and approve button. And it's clear
>> that
>> first two action links have to be placed at the one part of page (in
>> header near request title), and approval form at the other.
>> Also I want to use $wf->get_current_actions(); function, but how
>> should I distinguish where I should place current action, so I decided
>> to add additional property to the action tag. It's - block.
>> 
>> <action name="terminate"   block="state change"   class="..." />
>> <action name="place on hold"   block="state change"   class="..." />
>> <action name="approve request"   block="approval"   class="..." />
>> 
>> And modified get_current_actions(), so now I can call
>> my @actions = $wf->get_current_actions("approval");
>> or
>> my @actions = $wf->get_current_actions("state change");
>> And I get only actions that are members of specified block.
>> 
>> Patches are in the attachments, in case if you'll find this idea
>> interesting.
>> 
>> Thank you.
>> 
>> -- 
>> Best regards,
>> Ivan Paponov
>> iva...@gm... 

Re: [Perl-workflow-devel] Workflow Visualization

[Alexander K. <ak-...@cy...>]

Hi Ivan,

On Fri, Dec 12, 2008 at 05:14:06PM +0300, Ivan Paponov wrote:
> I don't know if devel list is right place for my question, but I don't
> know any other place where to post it.

Sure looks like the right place.

> After request modification, it will be good to show our user his new
> workflow, and show it in obvious, graphic way. We want to show him a
> picture with his new workflow.
> So my question is about drawing such pictures. Have anyone done such
> workflow visualizations already?

Yes, but ...

> PS: I tried to use graphviz tools for workflow visualization, but I
> wasn't satisfied with the result (alignment is awful, lines and text
> are crossing each other). See attachment.

... we used GraphViz, too. Works for us. Sure, it is sometimes not
particularly beautiful, but it's enough for the user to recognize
the structure.

We also thought about the other direction that you described and
were thinking about using business process modelling software, where
users can actually do that in a graphical way. Maybe that would be
another option, trying to export the workflow into such a format
(I believe BPML is the standard one, and it is XML, too) and see
if a (free) business process modelling software can draw a decent
graph of it.

Cheers,
  Alex
-- 
Dipl.-Math. Alexander Klink | IT-Security Engineer |    a....@cy...
 mobile: +49 (0)178 2121703 |          Cynops GmbH | http://www.cynops.de
----------------------------+----------------------+---------------------
      HRB 7833, Amtsgericht | USt-Id: DE 213094986 |     Geschäftsführer:
     Bad Homburg v. d. Höhe |                      |      Martin Bartosch

[Perl-workflow-devel] Workflow Visualization

[Ivan P. <iva...@gm...>]

Hi All,

I don't know if devel list is right place for my question, but I don't
know any other place where to post it.

Here is my problem. In our request management software, we would like
to give end-user an opportunity to modify request workflow according to
his company needs. There would be some kind of form with predefined
actions and conditions lists, editable states, etc. We are actually thinking
about it, so let's skip modification process for now and let's go further.
After request modification, it will be good to show our user his new
workflow, and show it in obvious, graphic way. We want to show him a
picture with his new workflow.
So my question is about drawing such pictures. Have anyone done such
workflow visualizations already?

PS: I tried to use graphviz tools for workflow visualization, but I
wasn't satisfied with the result (alignment is awful, lines and text
are crossing each other). See attachment.

--  
Best regards,
Ivan Paponov                                                  
iva...@gm...

Re: [Perl-workflow-devel] Workflow patch

[Ivan P. <iva...@gm...>]

'Section' or 'group' are both good for this attribute name.

As for "block", here is my explanation. I choose block on the analogy of "block-level"
html elements (http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.3)

> Yes, 'block' suggests that it might be something
> to do with 'stop'.

> I'd suggest 'section' (if I understand its function
> correctly), but your 'type' or 'group' would also,
> imho, be better than 'block'.

> Cheers, Phil.

> +++++++++++++++++++++++++++++++++++++
> phi...@un...
> Tel: +44 (0)161 257 3532
> +++++++++++++++++++++++++++++++++++++



> Jonas Brømsø Nielsen wrote:
>> Hola,
>>
>> I have had a look at Ivan's description of the functionality and it  
>> seems very useful, not to say powerful.
>>
>> So based on this I will move on with evaluating the actual patches.
>>
>> I only have one issue at this point and that is the word/attribute  
>> 'block', I would prefer another name for this.
>>
>> What about: type or group
>>
>> Let me know what you think.
>>
>>
>> jonasbn
>>
>>



-- 
Best regards,
Ivan Paponov                                                  
iva...@gm...

Re: [Perl-workflow-devel] Workflow patch

[phil r. <phi...@un...>]

Yes, 'block' suggests that it might be something
to do with 'stop'.

I'd suggest 'section' (if I understand its function
correctly), but your 'type' or 'group' would also,
imho, be better than 'block'.

Cheers, Phil.

+++++++++++++++++++++++++++++++++++++
phi...@un...
Tel: +44 (0)161 257 3532
+++++++++++++++++++++++++++++++++++++



Jonas Brømsø Nielsen wrote:
> Hola,
>
> I have had a look at Ivan's description of the functionality and it  
> seems very useful, not to say powerful.
>
> So based on this I will move on with evaluating the actual patches.
>
> I only have one issue at this point and that is the word/attribute  
> 'block', I would prefer another name for this.
>
> What about: type or group
>
> Let me know what you think.
>
>
> jonasbn
>
>
> On 09/12/2008, at 11.06, Jonas Brømsø Nielsen wrote:
>
>   
>> Hello All,
>>
>> Robert have now been added to our little group of developer - YAY!.
>>
>> Which mean that his patch will be added to the branch dedicated for  
>> this. A development release will be made as soon as he gives me a  
>> heads up.
>>
>> We have received some additional patches from Ivan Paponov (see  
>> below), who has also joined this list.
>>
>> If anybody has the time to evaluate the patches, please feel free.  
>> We can discuss them openly here and I am sure Ivan will be happy to  
>> answer any questions. If a preliminary review of the patches goes  
>> through, I will create a branch for inclusion and test of the patches.
>>
>> My $work TODO list is getting shorter, so I think I will be able to  
>> dedicate a lot of time over Christmas for Workflow.
>>
>>
>> jonasbn
>>
>> Begin forwarded message:
>>
>>     
>>> From: Ivan Paponov <iva...@gm...>
>>> Date: 8. dec 2008 21.59.04 GMT+01:00
>>> To: jo...@cp...
>>> Subject: Workflow patch
>>> Reply-To: Ivan Paponov <iva...@gm...>
>>>
>>> Hi Jonas,
>>>
>>> My name is Ivan. I'm developing request management system, and the
>>> base of it is Workflow framework. This module is really flexible and
>>> powerful, it's really a pleasure to work with it.
>>>
>>> But I found one detail that I'm missing in Workflow.
>>> Here is the situation.
>>> We created request, and placed it into Submitted state.
>>> In submitted state we have following actions: terminate, place on  
>>> hold
>>> and approve.
>>>
>>> <action name="terminate"   class="MyApp::Action::Terminate" />
>>> <action name="place on hold"   class="MyApp::Action::OnHold" />
>>> <action name="approve request"   class="MyApp::Action::Approve" />
>>>
>>> First two should be available on page as simple links, and third is
>>> approval form, with comment box and approve button. And it's clear  
>>> that
>>> first two action links have to be placed at the one part of page (in
>>> header near request title), and approval form at the other.
>>> Also I want to use $wf->get_current_actions(); function, but how
>>> should I distinguish where I should place current action, so I  
>>> decided
>>> to add additional property to the action tag. It's - block.
>>>
>>> <action name="terminate"   block="state change"   class="..." />
>>> <action name="place on hold"   block="state change"   class="..." />
>>> <action name="approve request"   block="approval"   class="..." />
>>>
>>> And modified get_current_actions(), so now I can call
>>> my @actions = $wf->get_current_actions("approval");
>>> or
>>> my @actions = $wf->get_current_actions("state change");
>>> And I get only actions that are members of specified block.
>>>
>>> Patches are in the attachments, in case if you'll find this idea
>>> interesting.
>>>
>>> Thank you.
>>>
>>> -- Best regards,
>>> Ivan Paponov
>>> iva...@gm...
>>>       
>> <State.pm.diff><Workflow.pm.diff>
>>     
>
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel
>   

Re: [Perl-workflow-devel] Workflow patch

[Jonas B. N. <jo...@gm...>]

Hola,

I have had a look at Ivan's description of the functionality and it  
seems very useful, not to say powerful.

So based on this I will move on with evaluating the actual patches.

I only have one issue at this point and that is the word/attribute  
'block', I would prefer another name for this.

What about: type or group

Let me know what you think.


jonasbn


On 09/12/2008, at 11.06, Jonas Brømsø Nielsen wrote:

> Hello All,
>
> Robert have now been added to our little group of developer - YAY!.
>
> Which mean that his patch will be added to the branch dedicated for  
> this. A development release will be made as soon as he gives me a  
> heads up.
>
> We have received some additional patches from Ivan Paponov (see  
> below), who has also joined this list.
>
> If anybody has the time to evaluate the patches, please feel free.  
> We can discuss them openly here and I am sure Ivan will be happy to  
> answer any questions. If a preliminary review of the patches goes  
> through, I will create a branch for inclusion and test of the patches.
>
> My $work TODO list is getting shorter, so I think I will be able to  
> dedicate a lot of time over Christmas for Workflow.
>
>
> jonasbn
>
> Begin forwarded message:
>
>> From: Ivan Paponov <iva...@gm...>
>> Date: 8. dec 2008 21.59.04 GMT+01:00
>> To: jo...@cp...
>> Subject: Workflow patch
>> Reply-To: Ivan Paponov <iva...@gm...>
>>
>> Hi Jonas,
>>
>> My name is Ivan. I'm developing request management system, and the
>> base of it is Workflow framework. This module is really flexible and
>> powerful, it's really a pleasure to work with it.
>>
>> But I found one detail that I'm missing in Workflow.
>> Here is the situation.
>> We created request, and placed it into Submitted state.
>> In submitted state we have following actions: terminate, place on  
>> hold
>> and approve.
>>
>> <action name="terminate"   class="MyApp::Action::Terminate" />
>> <action name="place on hold"   class="MyApp::Action::OnHold" />
>> <action name="approve request"   class="MyApp::Action::Approve" />
>>
>> First two should be available on page as simple links, and third is
>> approval form, with comment box and approve button. And it's clear  
>> that
>> first two action links have to be placed at the one part of page (in
>> header near request title), and approval form at the other.
>> Also I want to use $wf->get_current_actions(); function, but how
>> should I distinguish where I should place current action, so I  
>> decided
>> to add additional property to the action tag. It's - block.
>>
>> <action name="terminate"   block="state change"   class="..." />
>> <action name="place on hold"   block="state change"   class="..." />
>> <action name="approve request"   block="approval"   class="..." />
>>
>> And modified get_current_actions(), so now I can call
>> my @actions = $wf->get_current_actions("approval");
>> or
>> my @actions = $wf->get_current_actions("state change");
>> And I get only actions that are members of specified block.
>>
>> Patches are in the attachments, in case if you'll find this idea
>> interesting.
>>
>> Thank you.
>>
>> -- Best regards,
>> Ivan Paponov
>> iva...@gm...
> <State.pm.diff><Workflow.pm.diff>

[Perl-workflow-devel] Fwd: Workflow patch

[Jonas B. N. <jo...@gm...>]

Hello All,

Robert have now been added to our little group of developer - YAY!.

Which mean that his patch will be added to the branch dedicated for  
this. A development release will be made as soon as he gives me a  
heads up.

We have received some additional patches from Ivan Paponov (see  
below), who has also joined this list.

If anybody has the time to evaluate the patches, please feel free. We  
can discuss them openly here and I am sure Ivan will be happy to  
answer any questions. If a preliminary review of the patches goes  
through, I will create a branch for inclusion and test of the patches.

My $work TODO list is getting shorter, so I think I will be able to  
dedicate a lot of time over Christmas for Workflow.


jonasbn

Begin forwarded message:

> From: Ivan Paponov <iva...@gm...>
> Date: 8. dec 2008 21.59.04 GMT+01:00
> To: jo...@cp...
> Subject: Workflow patch
> Reply-To: Ivan Paponov <iva...@gm...>
>
> Hi Jonas,
>
> My name is Ivan. I'm developing request management system, and the
> base of it is Workflow framework. This module is really flexible and
> powerful, it's really a pleasure to work with it.
>
> But I found one detail that I'm missing in Workflow.
> Here is the situation.
> We created request, and placed it into Submitted state.
> In submitted state we have following actions: terminate, place on hold
> and approve.
>
> <action name="terminate"   class="MyApp::Action::Terminate" />
> <action name="place on hold"   class="MyApp::Action::OnHold" />
> <action name="approve request"   class="MyApp::Action::Approve" />
>
> First two should be available on page as simple links, and third is
> approval form, with comment box and approve button. And it's clear  
> that
> first two action links have to be placed at the one part of page (in
> header near request title), and approval form at the other.
> Also I want to use $wf->get_current_actions(); function, but how
> should I distinguish where I should place current action, so I decided
> to add additional property to the action tag. It's - block.
>
> <action name="terminate"   block="state change"   class="..." />
> <action name="place on hold"   block="state change"   class="..." />
> <action name="approve request"   block="approval"   class="..." />
>
> And modified get_current_actions(), so now I can call
> my @actions = $wf->get_current_actions("approval");
> or
> my @actions = $wf->get_current_actions("state change");
> And I get only actions that are members of specified block.
>
> Patches are in the attachments, in case if you'll find this idea
> interesting.
>
> Thank you.
>
> --  
> Best regards,
> Ivan Paponov
> iva...@gm...

Re: [Perl-workflow-devel] [rt.cpan.org #38024] all conditions with 'test' attirbute appears to be cached as 'evaluate'

[Jonas B. N. <jo...@gm...>]

Hi Robert,

Let me know what you username is on SourceForge. I cannot remember the  
process, perhaps you need to apply or something.

The project page is here:

	https://sourceforge.net/projects/perl-workflow/

I have created a branch named: test_condition

I can be reached via AIM: bjonasn or Jabber/Gtalk: jo...@gm...,  
if you require me to do something.

jonasbn

On 18/11/2008, at 21.10, Stockdale, Robert wrote:

> Jonas,
>
> I already have a SourceForge account so that is probably the easiest
> solution for everyone.
>
> Could you please grant me commit rights? Also, which branch would  
> you prefer
> I work in?
>
> --
> Bob Stockdale
> Administrative Computing Services
> University at Buffalo
> (716) 645-5334
> rf...@bu...
>
>
>> From: Jonas Brømsø Nielsen <jo...@gm...>
>> Date: Tue, 18 Nov 2008 14:45:59 -0500
>> To: Robert Stockdale <rf...@bu...>
>> Cc: "Brandt, Carl" <cb...@bu...>, Workflow development list
>> <per...@li...>
>> Subject: Re: [Perl-workflow-devel] [rt.cpan.org #38024] all  
>> conditions with
>> 'test' attirbute appears to be cached as 'evaluate'
>>
>> Hi Robert,
>>
>> You are more than welcome to get commit rights to our hosted
>> subversion repository.
>>
>> We are currently hosted at SourceForge so it requires an account  
>> there.
>>
>> Or you can send me the whole thing and I will sort it out.
>>
>> Thanks for taking the time and effort to do the extra iteration, I
>> think it will prove to be worth while.
>>
>> jonasbn
>>
>> On 18/11/2008, at 20.37, Stockdale, Robert wrote:
>>
>>> I attached the updated patch file to the RT ticket:
>>>
>>>   http://rt.cpan.org/Ticket/Display.html?id=38024
>>>
>>> Also, I wrote some automated tests for this change. What is the best
>>> way to
>>> get them into the distribution?
>>>
>>> --
>>> Bob Stockdale
>>> Administrative Computing Services
>>> University at Buffalo
>>> (716) 645-5334
>>> rf...@bu...
>>>
>>>
>>>> From: Jonas Brømsø Nielsen <jo...@gm...>
>>>> Date: Mon, 17 Nov 2008 15:22:42 -0500
>>>> To: "Brandt, Carl" <cb...@bu...>
>>>> Cc: Workflow development list <per...@li...>
>>>> Subject: Re: [Perl-workflow-devel] [rt.cpan.org #38024] all
>>>> conditions with
>>>> 'test' attirbute appears to be cached as 'evaluate'
>>>>
>>>> Sounds good.
>>>>
>>>> I was started to thinking along the lines of using Data::UUID to
>>>> generate the unique names, but that would probably just warp the
>>>> developers minds completely.
>>>>
>>>> I am looking for to the patch - we can get a development release  
>>>> out
>>>> of the door the moment it can be applied. This will also let other
>>>> developers evaluate the patch easily.
>>>>
>>>>
>>>> jonasbn
>>>>
>>>> On 17/11/2008, at 21.18, Jim Brandt wrote:
>>>>
>>>>> We discussed and came up with the following. Bob will be following
>>>>> up with a patch after some testing.
>>>>>
>>>>> * With regard to conditions, the name 'evaluate' is only used when
>>>>> creating the Condition::Evaluate object. It seems when conditions
>>>>> are evaluated, the sub just cycles through all conditions in the
>>>>> conditions array, so the name 'evaluate' isn't special in any way.
>>>>>
>>>>> * Naming for the auto-generated conditions
>>>>>
>>>>> When the condition fails, the name of the condition is written out
>>>>> to log4perl, so previous to the patch users would see that the
>>>>> 'evaluate' condition failed, which tells them that it was a 'test'
>>>>> condition, but does not tell them which one.
>>>>>
>>>>> Bob suggested even more detail in the name, like:
>>>>>
>>>>> "_$state\_$action\_condition\_$counter" so for example:
>>>>>
>>>>> _Begin_SA_condition_1
>>>>>
>>>>> If you had a problem, this would point you directly to the state-
>>>>>> action->in-line condition where your perl code is. I believe Bob
>>>>> said all of that information is easy to get inside the state  
>>>>> object.
>>>>>
>>>>>
>>>>> Jim
>>>>>
>>>>> Jonas Brømsø Nielsen wrote:
>>>>>> Hi Jim,
>>>>>> Thanks for the explanation, it was something along the lines of
>>>>>> what I
>>>>>> expected. Not being a user of this functionality however, I just
>>>>>> needed some hand-holding on the patch evaluation.
>>>>>> I will await your feedback from talking to Robert.
>>>>>> jonasbn
>>>>>> On 12/11/2008, at 21.37, Jim Brandt wrote:
>>>>>>> I'm ok with the principle of the patch. The special 'test'
>>>>>>> conditions are conditions with raw Perl code rather than an
>>>>>>> explicit
>>>>>>> condition object. The _create_condition_objects sub then  
>>>>>>> creates a
>>>>>>> condition object on the fly for each of these. The problem is  
>>>>>>> the
>>>>>>> name of each auto-generated condition object is hard-coded to
>>>>>>> 'evaluate'.
>>>>>>>
>>>>>>> I would want to verify if the 'evaluate' name is a magic name  
>>>>>>> used
>>>>>>> somewhere else in the code such that it expects it to be hard
>>>>>>> coded
>>>>>>> that way.
>>>>>>>
>>>>>>> Also, the patch uses the value of the test attribute as the  
>>>>>>> name.
>>>>>>> While this would guarantee that it will be unique, it could be  
>>>>>>> an
>>>>>>> arbitrarily large hash key (you can put in as much perl code as
>>>>>>> you
>>>>>>> want) and it wouldn't be very human readable if you were ever
>>>>>>> debugging.
>>>>>>>
>>>>>>> I would suggest adding some code to name it something like:
>>>>>>>
>>>>>>> "_" . <action_name> . "_condition_" . $counter
>>>>>>>
>>>>>>> where action_name is the name of the enclosing action and the
>>>>>>> counter is to allow us to have multiple 'test' type conditions  
>>>>>>> for
>>>>>>> an action. The leading underscore is just to indicate that is is
>>>>>>> private (auto-generated). So if you were debugging, the names of
>>>>>>> these condition objects would look something like:
>>>>>>>
>>>>>>> _MyAction_condition_1
>>>>>>>
>>>>>>> I work with Bob (Robert), so we'll discuss in the next day or  
>>>>>>> two.
>>>>>>>
>>>>>>> Jim
>>>>>>>
>>>>>>>
>>>>>>> Jonas Brømsø Nielsen wrote:
>>>>>>>> Hello All,
>>>>>>>> I have not received any feedback and I am reluctant to making a
>>>>>>>> development release for a one-line patch, I was hoping we would
>>>>>>>> be
>>>>>>>> able to evaluate this and decide simply on the contents of the
>>>>>>>> patch.
>>>>>>>> The issue is described below and the patch goes for line: 349  
>>>>>>>> in
>>>>>>>> HEAD
>>>>>>>> The line:
>>>>>>>>     name  => 'evaluate',
>>>>>>>> Roberts wants changed to:
>>>>>>>>     name => "_$condition_info->{test}",
>>>>>>>> I have not really gotten my head around the condition objects  
>>>>>>>> (I
>>>>>>>> should do this soon since our docs needs a serious update).
>>>>>>>> But this comment just above makes me hesitate applying the  
>>>>>>>> patch:
>>>>>>>>     # Special case: a 'test' denotes our 'evaluate' condition
>>>>>>>> So I guess the evaluate name is supposed to be hard-coded.
>>>>>>>> However
>>>>>>>> Roberts patch does seem to offer some flexibility. But then  
>>>>>>>> the _
>>>>>>>> (underscore) troubles me.
>>>>>>>> I am going to go over the tests covering this part later  
>>>>>>>> tonight,
>>>>>>>> but
>>>>>>>> if anybody has suggestions or opinions on this please feel free
>>>>>>>> to
>>>>>>>> write me (the list). Jim, I am particularly interested in your
>>>>>>>> opinion :)
>>>>>>>> Now I will go for my run to clear my head then I will look at  
>>>>>>>> the
>>>>>>>> code.
>>>>>>>> jonasbn
>>>>>>>> On 24/10/2008, at 23.55, Jonas Brømsø Nielsen wrote:
>>>>>>>>> Hiya Alll,
>>>>>>>>>
>>>>>>>>> We have received a patch from Robert Stockdale.
>>>>>>>>>
>>>>>>>>> If anybody has time to evaluate it, please feel free.
>>>>>>>>>
>>>>>>>>> jonasbn
>>>>>>>>>
>>>>>>>>> Begin forwarded message:
>>>>>>>>>
>>>>>>>>>> From: "Robert Stockdale via RT" <bug...@rt...>
>>>>>>>>>> Date: 29. sep 2008 21.48.42 GMT+02:00
>>>>>>>>>> To: undisclosed-recipients:;
>>>>>>>>>> Subject: [rt.cpan.org #38024] all conditions with 'test'
>>>>>>>>>> attirbute
>>>>>>>>>> appears to be cached as 'evaluate'
>>>>>>>>>> Reply-To: bug...@rt...
>>>>>>>>>>
>>>>>>>>>>  Queue: Workflow
>>>>>>>>>> Ticket <URL: http://rt.cpan.org/Ticket/Display.html? 
>>>>>>>>>> id=38024 >
>>>>>>>>>>
>>>>>>>>>> Hi Jonas,
>>>>>>>>>>
>>>>>>>>>> Sorry for the delay. I was able to confirm this bug.
>>>>>>>>>>
>>>>>>>>>> The name is being explicitly set to 'evaluate' in
>>>>>>>>>> Workflow::State::_create_condition_objects for all conditions
>>>>>>>>>> that
>>>>>>>>>> specify 'test' as an attribute in the xml configuration.  
>>>>>>>>>> This,
>>>>>>>>>> coupled
>>>>>>>>>> along with caching of condition results means that only the
>>>>>>>>>> first
>>>>>>>>>> 'evaluate' condition will actually be evaluated and each
>>>>>>>>>> subsequent
>>>>>>>>>> call
>>>>>>>>>> will use the cached result.
>>>>>>>>>>
>>>>>>>>>> Attached is a patch that will resolve the issue. Essentially
>>>>>>>>>> I am
>>>>>>>>>> just
>>>>>>>>>> taking the value of the 'test' attribute and naming the
>>>>>>>>>> condition
>>>>>>>>>> that,
>>>>>>>>>> with one small exception. Perl seems to have some issue with
>>>>>>>>>> keys
>>>>>>>>>> that
>>>>>>>>>> start with '!' so I prefixed it with an underscore. I tested
>>>>>>>>>> this
>>>>>>>>>> change
>>>>>>>>>> and it is working in my dev environment.
>>>>>>>>>>
>>>>>>>>>> An alternative option would be to allow the user to specify  
>>>>>>>>>> the
>>>>>>>>>> 'name'
>>>>>>>>>> attribute in the xml just like with any other condition. I  
>>>>>>>>>> did
>>>>>>>>>> not
>>>>>>>>>> exercise this option.
>>>>>>>>>>
>>>>>>>>>> -Bob
>>>>>>>>> <evaluate_condition_name.patch>
>>>>>>> --
>>>>>>> Jim Brandt
>>>>>>> Administrative Computing Services
>>>>>>> University at Buffalo
>>>>>>>
>>>>>
>>>>> --
>>>>> Jim Brandt
>>>>> Administrative Computing Services
>>>>> University at Buffalo
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>> great prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>> the world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> _______________________________________________
>>>> Perl-workflow-devel mailing list
>>>> Per...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel
>>>
>>
>