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

[Perl-workflow-devel] My very first post :)

[Alejandro I. <ai...@ya...>]

Hi all,

Thanks Jonas for pointing out the mailing list, and thanks to all for
such wonderful work, started out by Chris Winters and continued with
the current maintainer(s).

I have been fiddling with Workflow.pm for a while now for the p2ee
poroject, and now have the need to complete and figure out some stuff
to discuss here.

First, I would like to know the status of "Action Field Types" and if
no one is working on this, would like to volunteer to do some work on
it.

Second, and it's kind-a in-line with the above, there should be an
easy way to extend the attributes of any of the elements, starting
with Actions. For example, it should be easy to add new parameters to
the XML action tag both at the Workflow and the Action levels, and the
should be automatically added to the object and accessors added to
fiddle with them.

When starting to figure this out I noticed that
Workflow::Action::init() is not really doing anything but clobbering
$self->param, because the $params received is not what is expected for
things like $copy_params{class} to work. It seems that $params is
getting the _workflow object_ instead of a filtered Action of it's
type, So the accesors $self->name, class and such never have the
actual values. Here is the code I am referring to. If you dump $params
here you will see what I mean. Everything still works because the
public functions don't seem to use the acessors but rather scan the
wf_state in many cases.

########################################
# PRIVATE

sub init {
    my ( $self, $wf, $params ) = @_;

    # So we don't destroy the original...
    my %copy_params = %{$params};

    $self->class( $copy_params{class} );
    $self->name( $copy_params{name} );
    $self->description( $copy_params{description} );


Thanks beforehand, and sorry for the long first post.

Alejandro Imass

[Perl-workflow-devel] Presenting workflow at YAPC and OSCON

[Jim B. <cbr...@gm...>]

I suppose I should have mentioned this before, but I'll be giving talks
on Business Process Management with Workflow.pm at YAPC and OSCON this
year if anyone is attending.

http://yapc10.org/yn2009/talk/1935

http://en.oreilly.com/oscon2009/public/schedule/detail/8118

I'll pass along any interesting questions or comments.

Jim


-- 
Jim Brandt
cbr...@gm...

[Perl-workflow-devel] Presenting workflow at YAPC and OSCON

[Jim B. <cbr...@gm...>]

I suppose I should have mentioned this before, but I'll be giving talks 
on Business Process Management with Workflow.pm at YAPC and OSCON this 
year if anyone is attending.

http://yapc10.org/yn2009/talk/1935

http://en.oreilly.com/oscon2009/public/schedule/detail/8118

I'll pass along any interesting questions or comments.

Jim


-- 
Jim Brandt
cbr...@gm...

Re: [Perl-workflow-devel] in 1.32 add_config does not work for condition

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

Hi Sergei,

Just be aware that our developer releases, are developer releases, so  
distributing the major releases is more safe,

If you fall over something that needs immediate attention, just let me  
know and we can speed things up, it is often just a question of  
prioritization.

jonasbn

On 29/04/2009, at 02.32, Sergei Vyshenski wrote:

> Hi Jonas,
>
> Thank you very much for your patch.
>
> I have submitted minimalistic version of it to a FreeBSD  
> distribution of
> Workflow:
>
> http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/p5-Workflow/files/patch-lib-Workflow-Factory.pm?rev=1.1
>
> Now the FreeBSD port is numbered 1.32_1 which is understood by FreeBSD
> conventions as "revision 1 of release 1.32".
>
> The reason why I took such a liberty, is that FreeBSD prefers  
> monotonous
> alfa-numeric numbering of versions. This is essential for automatic
> audit and upgrade procedures. But (if my guess is correct) you decided
> to number developer releases in another (non-monotonous) way.
>
> Do you think that maybe in the future the following could be more  
> simple
> and intuitive scheme:
>
> 1.32 - release
> 1.32.1 - development atop of 1.32 (branch based on 1.32)
> 1.32.1.1 - development atop of 1.32.1 (branch based on 1.32.1)
> 1.32.2 - another development atop of 1.32
> ...
> 1.33 - release
> 1.33.1 - development atop of 1.33
> etc
>
> All the best, Sergei
>
>
> Jonas Brømsø Nielsen wrote:
>> I have just uploaded release 1.33_3 to CPAN, it addresses your  
>> problem.
>> Looking forward to your feedback.
>>
>> The code is also available from Subversion, in the branch:
>> add_config_bug, which is a branch based on 1.32.
>

Re: [Perl-workflow-devel] Can't get grouped actions

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

Hi Ivan,

I am still working on the release, I have just run out of TUITS.

Applying your patch broke some tests, which is perfectly okay, I just  
need to get them fixed before making the release.

jonasbn

On 27/04/2009, at 23.24, Ivan Paponov wrote:

> Hi Jonas,
>
> It would be very nice, thanks.
>
>> Hi Ivan,
>
>> Do you want me to make a dev release with your patch for general
>> evaluation?
>
>> jonasbn
>
>
> -- 
> Best regards,
> Ivan Paponov
> iva...@gm...
>

Re: [Perl-workflow-devel] in 1.32 add_config does not work for condition

[Sergei V. <sv...@pn...>]

Hi Jonas,

Thank you very much for your patch.

I have submitted minimalistic version of it to a FreeBSD distribution of
Workflow:

http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/p5-Workflow/files/patch-lib-Workflow-Factory.pm?rev=1.1

Now the FreeBSD port is numbered 1.32_1 which is understood by FreeBSD
conventions as "revision 1 of release 1.32".

The reason why I took such a liberty, is that FreeBSD prefers monotonous
alfa-numeric numbering of versions. This is essential for automatic
audit and upgrade procedures. But (if my guess is correct) you decided
to number developer releases in another (non-monotonous) way.

Do you think that maybe in the future the following could be more simple
and intuitive scheme:

1.32 - release
1.32.1 - development atop of 1.32 (branch based on 1.32)
1.32.1.1 - development atop of 1.32.1 (branch based on 1.32.1)
1.32.2 - another development atop of 1.32
...
1.33 - release
1.33.1 - development atop of 1.33
etc

All the best, Sergei


Jonas Brømsø Nielsen wrote:
> I have just uploaded release 1.33_3 to CPAN, it addresses your problem.
> Looking forward to your feedback.
> 
> The code is also available from Subversion, in the branch:
> add_config_bug, which is a branch based on 1.32.

Re: [Perl-workflow-devel] Can't get grouped actions

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

Hi Ivan,

I will have it ready for CPAN tomorrow.

jonasbn

On 27/04/2009, at 23.24, Ivan Paponov wrote:

> Hi Jonas,
>
> It would be very nice, thanks.
>
>> Hi Ivan,
>
>> Do you want me to make a dev release with your patch for general
>> evaluation?
>
>> jonasbn
>
>
> -- 
> Best regards,
> Ivan Paponov
> iva...@gm...
>

Re: [Perl-workflow-devel] Can't get grouped actions

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

Hi Jonas,

It would be very nice, thanks.

> Hi Ivan,

> Do you want me to make a dev release with your patch for general  
> evaluation?

> jonasbn


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

Re: [Perl-workflow-devel] Can't get grouped actions

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

Hi Ivan,

Do you want me to make a dev release with your patch for general  
evaluation?

jonasbn

On 27/04/2009, at 23.03, Ivan Paponov wrote:

> Andrew, Jim,
> Thanks a lot for the explanation.
>
> Anyone, with commit rights,
> please change one line in State.pm (sub get_available_action_names)
>
> my $action_group = FACTORY->{_action_config}{$action_name}{'group'};
> should be
> my $action_group = FACTORY->{_action_config}{$self->type()} 
> {$action_name}{'group'};
>
> Thanks.
>
>> If I'm understanding the question, your description is correct. If  
>> you
>> don't provide a type for your actions, it uses 'default' as a
>> placeholder. This was also done for backward compatibility.
>
>> But if you want to use types, they need to match between the workflow
>> config and the actions config. This allows you to have one workflow
>> "engine" support multiple types, and each type can have an action  
>> with
>> the same name but different implementations (like two Submit actions
>> that do different things for different types). This snippet tries to
>> explain this set-up:
>
>> http://search.cpan.org/~jonasbn/Workflow-1.32/lib/Workflow/Action.pm#CONFIGURATION
>
>> Any suggestions for making the docs clearer are welcome.
>
>> Jim
>
>> Andrew O'Brien wrote:
>>> Hi Ivan,
>>>
>>> We have exactly the same type set in the workflow.xml as in our
>>> associated actions.xml.
>>>
>>> Ie given a workflow "helpdesk" and the following files:
>>>
>>> wf_helpdesk.xml
>>> wf_helpdesk_action.xml
>>> wf_helpdesk_condition.xml
>>>
>>> .. Each of these files has a <type>helpdesk</type> entity.
>>>
>>> As far as I under stand the config structure, that's almost  
>>> required but
>>> if not, it certainly saves a lot of confusion.
>>>
>>> In that case you could just call ->type() and use it directly  
>>> which I
>>> believe is the way things should be set up.
>>>
>>> Can anyone else comment whether setting the same type value in all  
>>> files
>>> for a worklog is The Way Things Are Supposed To Be?
>>>
>>> Cheers,
>>>
>>> Andrew
>>>
>
> -- 
> Best regards,
> Ivan Paponov
> iva...@gm...
>
>
> ------------------------------------------------------------------------------
> Crystal Reports &#45; New Free Runtime and 30 Day Trial
> Check out the new simplified licensign option that enables unlimited
> royalty&#45;free distribution of the report engine for externally  
> facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

Re: [Perl-workflow-devel] Can't get grouped actions

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

Andrew, Jim,
Thanks a lot for the explanation.

Anyone, with commit rights,
please change one line in State.pm (sub get_available_action_names)

my $action_group = FACTORY->{_action_config}{$action_name}{'group'};
should be
my $action_group = FACTORY->{_action_config}{$self->type()}{$action_name}{'group'};

Thanks.

> If I'm understanding the question, your description is correct. If you
> don't provide a type for your actions, it uses 'default' as a 
> placeholder. This was also done for backward compatibility.

> But if you want to use types, they need to match between the workflow 
> config and the actions config. This allows you to have one workflow 
> "engine" support multiple types, and each type can have an action with
> the same name but different implementations (like two Submit actions 
> that do different things for different types). This snippet tries to 
> explain this set-up:

> http://search.cpan.org/~jonasbn/Workflow-1.32/lib/Workflow/Action.pm#CONFIGURATION

> Any suggestions for making the docs clearer are welcome.

> Jim

> Andrew O'Brien wrote:
>> Hi Ivan,
>> 
>> We have exactly the same type set in the workflow.xml as in our
>> associated actions.xml.
>> 
>> Ie given a workflow "helpdesk" and the following files:
>> 
>>  wf_helpdesk.xml
>>  wf_helpdesk_action.xml
>>  wf_helpdesk_condition.xml
>> 
>> .. Each of these files has a <type>helpdesk</type> entity.
>> 
>> As far as I under stand the config structure, that's almost required but
>> if not, it certainly saves a lot of confusion.
>> 
>> In that case you could just call ->type() and use it directly which I
>> believe is the way things should be set up.
>> 
>> Can anyone else comment whether setting the same type value in all files
>> for a worklog is The Way Things Are Supposed To Be?
>> 
>> Cheers,
>> 
>> Andrew
>> 

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

Re: [Perl-workflow-devel] Can't get grouped actions

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

If I'm understanding the question, your description is correct. If you 
don't provide a type for your actions, it uses 'default' as a 
placeholder. This was also done for backward compatibility.

But if you want to use types, they need to match between the workflow 
config and the actions config. This allows you to have one workflow 
"engine" support multiple types, and each type can have an action with 
the same name but different implementations (like two Submit actions 
that do different things for different types). This snippet tries to 
explain this set-up:

http://search.cpan.org/~jonasbn/Workflow-1.32/lib/Workflow/Action.pm#CONFIGURATION

Any suggestions for making the docs clearer are welcome.

Jim

Andrew O'Brien wrote:
> Hi Ivan,
> 
> We have exactly the same type set in the workflow.xml as in our
> associated actions.xml.
> 
> Ie given a workflow "helpdesk" and the following files:
> 
>  wf_helpdesk.xml
>  wf_helpdesk_action.xml
>  wf_helpdesk_condition.xml
> 
> .. Each of these files has a <type>helpdesk</type> entity.
> 
> As far as I under stand the config structure, that's almost required but
> if not, it certainly saves a lot of confusion.
> 
> In that case you could just call ->type() and use it directly which I
> believe is the way things should be set up.
> 
> Can anyone else comment whether setting the same type value in all files
> for a worklog is The Way Things Are Supposed To Be?
> 
> Cheers,
> 
> Andrew
> 
>> -----Original Message-----
>> From: Ivan Paponov [mailto:iva...@gm...] 
>> Sent: Saturday, 25 April 2009 5:40 PM
>> To: Andrew O'Brien; per...@li...
>> Subject: Re: [Perl-workflow-devel] Can't get grouped actions
>>
>> Hi Andrew,
>>
>> Thanks for your answer.
>>
>> I didn't have time to work over that issue earlier, but now I would
>> like to fix it. Here are my thoughts about it.
>>
>> We have action types (didn't pay much attention it it before 
>> actually), so that means line in
>> State.pm, which I submitted in group patch, won't work.
>> That one:
>>      my $action_group = 
>> FACTORY->{_action_config}{$action_name}{'group'};
>>
>> (Actually I'm still wondering why it worked in 0.31)
>> So we need to change it to something like
>>    my $type = exists $some_type ? $some_type : 'default';
>>    FACTORY->{_action_config}{$type}{$action_name}{'group'}
>>
>> So where can we find that $some_type variable?
>> In state we have $self->type() which is workflow type, but I need
>> clarification here - how does workflow type corresponds with action
>> types?
>> Actually, when I look at the XML structure of <workflow> it's 
>> clear that I have
>> workflow, with some type, and number of actions that are it's
>> children. And it's clear without action type definition.
>> But actually it's not clear in script, because all actions go under
>> 'default' key, but not not under 'Workflow type' key.
>>
>> So, here is my main question, where I can find action type variable in
>> State.pm? And should I mark all actions in my_type_workflow.xml with
>> workflow type?
>> (I don't mind my_type_actions.xml here, because State.pm doesn't work
>> with it at all, and actions are taken from my_type_workflow.xml file)
>>
>>>> From: Ivan Paponov [mailto:iva...@gm...] 
>>>> Sent: Monday, 2 March 2009 10:37 AM
>>
>>> Hi Ivan,
>>>> Recently, I updated workflow 0.31 to 1.32 and I faced with 
>> one problem
>>>> in my system. Links that were connected to actions disappeared. I
>>>> didn't have much time to go deep into debugging, but here is what I
>>>> found for now.
>>>>
>>>> I retrieve actions with get_current_actions($group) function.
>>>> It refers to get_available_action_names($self,$group), which 
>>>> is in State.pm
>>>> I analyzed that function, and I found that
>>>> my $action_group = 
>> FACTORY->{_action_config}{$action_name}{'group'};
>>>> returns nothing.
>>>> So, I looked at FACTORY->{_action_config} and found out that all
>>>> actions are under 'default' key. I added that key:
>>>> my $action_group = 
>>>> FACTORY->{_action_config}{'default'}{$action_name}{'group'};
>>>> And my action links returned on the screen.
>>> Each of your action, condition and top-level workflow files need to
>>> define the <type> parameter - One of the other developers here was
>>> bitten by this a while back :-)
>>> Eg:
>>> my_type_here.xml:
>>> <workflow type="my_type_here">
>>>   ...
>>> </workflow>
>>> my_type_here_action.xml:
>>> <action>
>>>   <type>my_type_here</type>
>>>   ...
>>> </action>
>>> Etc.
>>> Then things should work as expected. The hash key is the 
>> workflow type
>>> from memory which defaults to 'default' if not set.
>>> Cheers,
>>> Andrew
>>
>>
>> -- 
>> Best regards,
>> Ivan Paponov                                                  
>> iva...@gm...
>>
>>
> 
> 
> ------------------------------------------------------------------------------
> Crystal Reports &#45; New Free Runtime and 30 Day Trial
> Check out the new simplified licensign option that enables unlimited
> royalty&#45;free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

-- 
Jim Brandt
Administrative Computing Services
University at Buffalo

Re: [Perl-workflow-devel] Can't get grouped actions

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

Hi Ivan,

We have exactly the same type set in the workflow.xml as in our
associated actions.xml.

Ie given a workflow "helpdesk" and the following files:

 wf_helpdesk.xml
 wf_helpdesk_action.xml
 wf_helpdesk_condition.xml

.. Each of these files has a <type>helpdesk</type> entity.

As far as I under stand the config structure, that's almost required but
if not, it certainly saves a lot of confusion.

In that case you could just call ->type() and use it directly which I
believe is the way things should be set up.

Can anyone else comment whether setting the same type value in all files
for a worklog is The Way Things Are Supposed To Be?

Cheers,

Andrew

> -----Original Message-----
> From: Ivan Paponov [mailto:iva...@gm...] 
> Sent: Saturday, 25 April 2009 5:40 PM
> To: Andrew O'Brien; per...@li...
> Subject: Re: [Perl-workflow-devel] Can't get grouped actions
> 
> Hi Andrew,
> 
> Thanks for your answer.
> 
> I didn't have time to work over that issue earlier, but now I would
> like to fix it. Here are my thoughts about it.
> 
> We have action types (didn't pay much attention it it before 
> actually), so that means line in
> State.pm, which I submitted in group patch, won't work.
> That one:
>      my $action_group = 
> FACTORY->{_action_config}{$action_name}{'group'};
> 
> (Actually I'm still wondering why it worked in 0.31)
> So we need to change it to something like
>    my $type = exists $some_type ? $some_type : 'default';
>    FACTORY->{_action_config}{$type}{$action_name}{'group'}
> 
> So where can we find that $some_type variable?
> In state we have $self->type() which is workflow type, but I need
> clarification here - how does workflow type corresponds with action
> types?
> Actually, when I look at the XML structure of <workflow> it's 
> clear that I have
> workflow, with some type, and number of actions that are it's
> children. And it's clear without action type definition.
> But actually it's not clear in script, because all actions go under
> 'default' key, but not not under 'Workflow type' key.
> 
> So, here is my main question, where I can find action type variable in
> State.pm? And should I mark all actions in my_type_workflow.xml with
> workflow type?
> (I don't mind my_type_actions.xml here, because State.pm doesn't work
> with it at all, and actions are taken from my_type_workflow.xml file)
> 
> >> From: Ivan Paponov [mailto:iva...@gm...] 
> >> Sent: Monday, 2 March 2009 10:37 AM
> 
> 
> > Hi Ivan,
> 
> >> Recently, I updated workflow 0.31 to 1.32 and I faced with 
> one problem
> >> in my system. Links that were connected to actions disappeared. I
> >> didn't have much time to go deep into debugging, but here is what I
> >> found for now.
> >> 
> >> I retrieve actions with get_current_actions($group) function.
> >> It refers to get_available_action_names($self,$group), which 
> >> is in State.pm
> >> I analyzed that function, and I found that
> >> my $action_group = 
> FACTORY->{_action_config}{$action_name}{'group'};
> >> returns nothing.
> >> So, I looked at FACTORY->{_action_config} and found out that all
> >> actions are under 'default' key. I added that key:
> >> my $action_group = 
> >> FACTORY->{_action_config}{'default'}{$action_name}{'group'};
> >> And my action links returned on the screen.
> 
> > Each of your action, condition and top-level workflow files need to
> > define the <type> parameter - One of the other developers here was
> > bitten by this a while back :-)
> 
> > Eg:
> 
> > my_type_here.xml:
> > <workflow type="my_type_here">
> >   ...
> > </workflow>
> 
> > my_type_here_action.xml:
> > <action>
> >   <type>my_type_here</type>
> >   ...
> > </action>
> 
> > Etc.
> 
> > Then things should work as expected. The hash key is the 
> workflow type
> > from memory which defaults to 'default' if not set.
> 
> > Cheers,
> 
> > Andrew
> 
> 
> 
> -- 
> Best regards,
> Ivan Paponov                                                  
> iva...@gm...
> 
> 

Re: [Perl-workflow-devel] Can't get grouped actions

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

Hi Andrew,

Thanks for your answer.

I didn't have time to work over that issue earlier, but now I would
like to fix it. Here are my thoughts about it.

We have action types (didn't pay much attention it it before actually), so that means line in
State.pm, which I submitted in group patch, won't work.
That one:
     my $action_group = FACTORY->{_action_config}{$action_name}{'group'};

(Actually I'm still wondering why it worked in 0.31)
So we need to change it to something like
   my $type = exists $some_type ? $some_type : 'default';
   FACTORY->{_action_config}{$type}{$action_name}{'group'}

So where can we find that $some_type variable?
In state we have $self->type() which is workflow type, but I need
clarification here - how does workflow type corresponds with action
types?
Actually, when I look at the XML structure of <workflow> it's clear that I have
workflow, with some type, and number of actions that are it's
children. And it's clear without action type definition.
But actually it's not clear in script, because all actions go under
'default' key, but not not under 'Workflow type' key.

So, here is my main question, where I can find action type variable in
State.pm? And should I mark all actions in my_type_workflow.xml with
workflow type?
(I don't mind my_type_actions.xml here, because State.pm doesn't work
with it at all, and actions are taken from my_type_workflow.xml file)

>> From: Ivan Paponov [mailto:iva...@gm...] 
>> Sent: Monday, 2 March 2009 10:37 AM


> Hi Ivan,

>> Recently, I updated workflow 0.31 to 1.32 and I faced with one problem
>> in my system. Links that were connected to actions disappeared. I
>> didn't have much time to go deep into debugging, but here is what I
>> found for now.
>> 
>> I retrieve actions with get_current_actions($group) function.
>> It refers to get_available_action_names($self,$group), which 
>> is in State.pm
>> I analyzed that function, and I found that
>> my $action_group = FACTORY->{_action_config}{$action_name}{'group'};
>> returns nothing.
>> So, I looked at FACTORY->{_action_config} and found out that all
>> actions are under 'default' key. I added that key:
>> my $action_group = 
>> FACTORY->{_action_config}{'default'}{$action_name}{'group'};
>> And my action links returned on the screen.

> Each of your action, condition and top-level workflow files need to
> define the <type> parameter - One of the other developers here was
> bitten by this a while back :-)

> Eg:

> my_type_here.xml:
> <workflow type="my_type_here">
>   ...
> </workflow>

> my_type_here_action.xml:
> <action>
>   <type>my_type_here</type>
>   ...
> </action>

> Etc.

> Then things should work as expected. The hash key is the workflow type
> from memory which defaults to 'default' if not set.

> Cheers,

> Andrew



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

[Perl-workflow-devel] CPAN cleanup

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

Hello All,

I have removed old releases and old development releases from CPAN,  
these are still available from backpan if you need them.

So now we have the following releases available on CPAN:

1.32
1.31
1.30

+ the developer releases for 1.33 (1.33_2 and 1.33_3).

I hope this will address the failing test report for 0.27 we keep  
receiving.

Have a nice Sunday,

jonasbn

Re: [Perl-workflow-devel] in 1.32 add_config does not work for condition

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

Hi Sergei,

I have just uploaded release 1.33_3 to CPAN, it addresses your  
problem. Looking forward to your feedback.

Thanks for the code snippet below, it really made it easier to proceed.

The code is also available from Subversion, in the branch:  
add_config_bug, which is a branch based on 1.32.

jonasbn

On 17/04/2009, at 15.42, Sergei Vyshenski wrote:

> Hi,
>
> Jim Brandt wrote:
>> Could you add some tests to the test file you found that demonstrate
>> this problem? It sounds like you may have already done this as part  
>> of
>> your testing and it would be really helpful to have the tests.
>
> Yes, please find attached file, which runs ok with 0.31 and fails
> with 1.32.
>
> Maybe the following could be of help.
>
> On the way from 0.31 to 1.32 a function _add_condition_config was
> changed in such a way, that now it has one extra "foreach". And now
> the arguments (which add_config passes to the _add_condition_config
> function) happen to be _not_ compatible with this extra "foreach".
>
> All the best, Sergei
>
>
> # -*-perl-*-
>
> use strict;
> use lib 't';
> use TestUtil;
> use constant NUM_TESTS => 3;
> use Test::More;
> use Test::Exception;
>
> plan tests => NUM_TESTS;
>
> require Workflow::Factory;
>
> my @conditions = ({
>          name => 'HasUser',
>          class => 'TestApp::Condition::HasUser'
>        });
>
> my @actions = ({
>          name => 'TIX_NEW',
>          class => 'TestApp::Action::TicketCreate'
>        });
>
> my $factory = Workflow::Factory->instance();
>
> is( ref( $factory ), 'Workflow::Factory',
>    'Return from instance() correct type' );
>
> $factory->add_config( condition  => \@conditions );
> lives_ok{$factory->get_condition('HasUser')};
>
> $factory->add_config( action  => \@actions );
> ok(exists $factory->{_action_config}, "action config added");
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p_______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

Re: [Perl-workflow-devel] CPAN Testers Daily Summary Report

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

Hello All,

I have talked to one of the testers on IRC and the problems are not  
related to our development release of Workflow. The problem was  
related to a buggy CPANPLUS::Dist::YACSmoke 0.33_01, which has now  
been fixed.

jonasbn

On 18/04/2009, at 11.01, Jonas Brømsø Nielsen wrote:

> Hello All,
>
> We have received some reports of failing tests related to  
> Workflow-1.33_2
>
> It does however seem to be a broken DateTime causing the trouble.
>
> I have written to the testers in question, hoping the can assert  
> that my diagnostics are correct.
>
> jonasbn
>
> Begin forwarded message:
>
>> From: CPAN Tester Report Server <do_...@cp...>
>> Date: 1. apr 2009 04.01.33 GMT+02:00
>> To: "Jonas B. Nielsen" <JO...@cp...>
>> Subject: CPAN Testers Daily Summary Report
>>
>> Dear Jonas B. Nielsen,
>>
>> Please find below the latest reports for your distributions,  
>> generated by CPAN Testers, from the last 24 hours.
>>
>> To set your preferences for what you wish to have reported in this  
>> Daily Summary, please visit the CPAN Testers Preferences system at https://prefs.cpantesters.org 
>> .
>>
>>
>> Workflow-1.33_2:
>> - x86_64-linux-thread-multi / 5.10.0:
>> - FAIL http://nntp.x.perl.org/group/perl.cpan.testers/3599100
>>
>> - i386-freebsd-thread-multi-64int / 5.10.0:
>> - FAIL http://nntp.x.perl.org/group/perl.cpan.testers/3595369
>>
>>
>>
>> If you have an issue with a particular report, or wish to gain  
>> further information from the tester, please use the 'Find A Tester'  
>> tool at http://stats.cpantesters.org/cpanmail.html, using the NNTP  
>> ID of the report to locate the correct email address.
>>
>> If you wish to unsubscribe from these notifications, please login  
>> to the CPAN Testers Preferences system, with your PAUSE  
>> credentials, and disable CPAN Testers notifications permanently or  
>> temporarily. If you have problems with accessing the site, please  
>> contact Barbie <ba...@cp...> and request to be removed from the  
>> automatic mailings.
>>
>> Thanks,
>> The CPAN Testers
>> -- 
>> Reports:     http://www.cpantesters.org
>> Statistics:  http://stats.cpantesters.org
>> Wiki:        http://wiki.cpantesters.org
>> Preferences: https://prefs.cpantesters.org
>

[Perl-workflow-devel] Fwd: CPAN Testers Daily Summary Report

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

Hello All,

We have received some reports of failing tests related to  
Workflow-1.33_2

It does however seem to be a broken DateTime causing the trouble.

I have written to the testers in question, hoping the can assert that  
my diagnostics are correct.

jonasbn

Begin forwarded message:

> From: CPAN Tester Report Server <do_...@cp...>
> Date: 1. apr 2009 04.01.33 GMT+02:00
> To: "Jonas B. Nielsen" <JO...@cp...>
> Subject: CPAN Testers Daily Summary Report
>
> Dear Jonas B. Nielsen,
>
> Please find below the latest reports for your distributions,  
> generated by CPAN Testers, from the last 24 hours.
>
> To set your preferences for what you wish to have reported in this  
> Daily Summary, please visit the CPAN Testers Preferences system at https://prefs.cpantesters.org 
> .
>
>
> Workflow-1.33_2:
> - x86_64-linux-thread-multi / 5.10.0:
>  - FAIL http://nntp.x.perl.org/group/perl.cpan.testers/3599100
>
> - i386-freebsd-thread-multi-64int / 5.10.0:
>  - FAIL http://nntp.x.perl.org/group/perl.cpan.testers/3595369
>
>
>
> If you have an issue with a particular report, or wish to gain  
> further information from the tester, please use the 'Find A Tester'  
> tool at http://stats.cpantesters.org/cpanmail.html, using the NNTP  
> ID of the report to locate the correct email address.
>
> If you wish to unsubscribe from these notifications, please login to  
> the CPAN Testers Preferences system, with your PAUSE credentials,  
> and disable CPAN Testers notifications permanently or temporarily.  
> If you have problems with accessing the site, please contact Barbie <ba...@cp... 
> > and request to be removed from the automatic mailings.
>
> Thanks,
> The CPAN Testers
> -- 
> Reports:     http://www.cpantesters.org
> Statistics:  http://stats.cpantesters.org
> Wiki:        http://wiki.cpantesters.org
> Preferences: https://prefs.cpantesters.org

Re: [Perl-workflow-devel] in 1.32 add_config does not work for condition

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

Hi Sergei,

Marvellous - sorry for breaking your end though.

I will look into it ASAP.

jonasbn

On 17/04/2009, at 15.42, Sergei Vyshenski wrote:

> Hi,
>
> Jim Brandt wrote:
>> Could you add some tests to the test file you found that demonstrate
>> this problem? It sounds like you may have already done this as part  
>> of
>> your testing and it would be really helpful to have the tests.
>
> Yes, please find attached file, which runs ok with 0.31 and fails
> with 1.32.
>
> Maybe the following could be of help.
>
> On the way from 0.31 to 1.32 a function _add_condition_config was
> changed in such a way, that now it has one extra "foreach". And now
> the arguments (which add_config passes to the _add_condition_config
> function) happen to be _not_ compatible with this extra "foreach".
>
> All the best, Sergei
>
>
> # -*-perl-*-
>
> use strict;
> use lib 't';
> use TestUtil;
> use constant NUM_TESTS => 3;
> use Test::More;
> use Test::Exception;
>
> plan tests => NUM_TESTS;
>
> require Workflow::Factory;
>
> my @conditions = ({
>          name => 'HasUser',
>          class => 'TestApp::Condition::HasUser'
>        });
>
> my @actions = ({
>          name => 'TIX_NEW',
>          class => 'TestApp::Action::TicketCreate'
>        });
>
> my $factory = Workflow::Factory->instance();
>
> is( ref( $factory ), 'Workflow::Factory',
>    'Return from instance() correct type' );
>
> $factory->add_config( condition  => \@conditions );
> lives_ok{$factory->get_condition('HasUser')};
>
> $factory->add_config( action  => \@actions );
> ok(exists $factory->{_action_config}, "action config added");
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p_______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

Re: [Perl-workflow-devel] in 1.32 add_config does not work for condition

[Sergei V. <sv...@pn...>]

Hi,

Jim Brandt wrote:
> Could you add some tests to the test file you found that demonstrate
> this problem? It sounds like you may have already done this as part of
> your testing and it would be really helpful to have the tests.

Yes, please find attached file, which runs ok with 0.31 and fails
with 1.32.

Maybe the following could be of help.

On the way from 0.31 to 1.32 a function _add_condition_config was
changed in such a way, that now it has one extra "foreach". And now
the arguments (which add_config passes to the _add_condition_config
function) happen to be _not_ compatible with this extra "foreach".

All the best, Sergei

Re: [Perl-workflow-devel] in 1.32 add_config does not work for condition

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

Hi Sergei,

It has not been our goal to break backwards compatibility, since we  
aim for stability,

So if this has work earlier it sounds like we have introduced a bug.

I will investigate over the weekend and get back to you.

jonasbn

On 17/04/2009, at 00.01, Sergei Vyshenski wrote:

> Hi,
>
> A tiresome problem has knocked me after a move to ver. 1.32.
>
> Let @entry be something like
>
> my @entry = ({
>          name => 'some name',
>          class => 'some class',
>          ...
>        });
>
> Then a call
>
> $factory->add_config( persister  => \@entry );
>
> is similar to those used in some of the tests supplied with ver 1.32  
> and
> works fine. But a call
>
> $factory->add_config( condition  => \@entry );
>
> has no analog in the supplied tests and seems not working. That is no
> data structures associated with condition are created. This could be
> explicitly verified with use of
>
> print STDERR Dumper($factory)."\n";
>
> after calling add_config.
>
> This problem was absent in ver 0.31.
>
> This problem prevents correct start of the OpenXPKI server (which is a
> PKI related project) with default configuration files related to its
> workflows.
>
> Do you think this could be a bug, or just a new feature?
> If the latter, could you please recommend a correct way to add
> configuration for a condition.
>
> Note that OpenXPKI uses both add_config and also add_config_from_file
> (which works fine) because of historical reasons. If add_config is out
> of fashion today, do you think that OpenXPKI should completely migrate
> to add_config_from_file? This would be quite a job to do though.
>
> All the best, Sergei
>
> P.S. Adding config for action seems to have similar problems. And for
> validator too...
>
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

Re: [Perl-workflow-devel] in 1.32 add_config does not work for condition

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

Sergei,

Could you add some tests to the test file you found that demonstrate 
this problem? It sounds like you may have already done this as part of 
your testing and it would be really helpful to have the tests.

Thanks,
Jim

Sergei Vyshenski wrote:
> Hi,
> 
> A tiresome problem has knocked me after a move to ver. 1.32.
> 
> Let @entry be something like
> 
> my @entry = ({
>           name => 'some name',
>           class => 'some class',
>           ...
>         });
> 
> Then a call
> 
> $factory->add_config( persister  => \@entry );
> 
> is similar to those used in some of the tests supplied with ver 1.32 and
> works fine. But a call
> 
> $factory->add_config( condition  => \@entry );
> 
> has no analog in the supplied tests and seems not working. That is no
> data structures associated with condition are created. This could be
> explicitly verified with use of
> 
> print STDERR Dumper($factory)."\n";
> 
> after calling add_config.
> 
> This problem was absent in ver 0.31.
> 
> This problem prevents correct start of the OpenXPKI server (which is a
> PKI related project) with default configuration files related to its
> workflows.
> 
> Do you think this could be a bug, or just a new feature?
> If the latter, could you please recommend a correct way to add
> configuration for a condition.
> 
> Note that OpenXPKI uses both add_config and also add_config_from_file
> (which works fine) because of historical reasons. If add_config is out
> of fashion today, do you think that OpenXPKI should completely migrate
> to add_config_from_file? This would be quite a job to do though.
> 
> All the best, Sergei
> 
> P.S. Adding config for action seems to have similar problems. And for
> validator too...
> 
> 
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and 
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today. 
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> 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] in 1.32 add_config does not work for condition

[Sergei V. <sv...@pn...>]

Hi,

A tiresome problem has knocked me after a move to ver. 1.32.

Let @entry be something like

my @entry = ({
          name => 'some name',
          class => 'some class',
          ...
        });

Then a call

$factory->add_config( persister  => \@entry );

is similar to those used in some of the tests supplied with ver 1.32 and
works fine. But a call

$factory->add_config( condition  => \@entry );

has no analog in the supplied tests and seems not working. That is no
data structures associated with condition are created. This could be
explicitly verified with use of

print STDERR Dumper($factory)."\n";

after calling add_config.

This problem was absent in ver 0.31.

This problem prevents correct start of the OpenXPKI server (which is a
PKI related project) with default configuration files related to its
workflows.

Do you think this could be a bug, or just a new feature?
If the latter, could you please recommend a correct way to add
configuration for a condition.

Note that OpenXPKI uses both add_config and also add_config_from_file
(which works fine) because of historical reasons. If add_config is out
of fashion today, do you think that OpenXPKI should completely migrate
to add_config_from_file? This would be quite a job to do though.

All the best, Sergei

P.S. Adding config for action seems to have similar problems. And for
validator too...

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

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

Hello All and especially Andrew,

I have just created a branch for the patch. (dynamic_load). The patch  
has been applied and a developer release has been uploaded to CPAN.  
Please test release 1.33_1 if you have time to do so.

Feedback welcome.

Working on the branch is also encouraged.

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

Re: [Perl-workflow-devel] Can't get grouped actions

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

> From: Ivan Paponov [mailto:iva...@gm...] 
> Sent: Monday, 2 March 2009 10:37 AM


Hi Ivan,

> Recently, I updated workflow 0.31 to 1.32 and I faced with one problem
> in my system. Links that were connected to actions disappeared. I
> didn't have much time to go deep into debugging, but here is what I
> found for now.
> 
> I retrieve actions with get_current_actions($group) function.
> It refers to get_available_action_names($self,$group), which 
> is in State.pm
> I analyzed that function, and I found that
> my $action_group = FACTORY->{_action_config}{$action_name}{'group'};
> returns nothing.
> So, I looked at FACTORY->{_action_config} and found out that all
> actions are under 'default' key. I added that key:
> my $action_group = 
> FACTORY->{_action_config}{'default'}{$action_name}{'group'};
> And my action links returned on the screen.

Each of your action, condition and top-level workflow files need to
define the <type> parameter - One of the other developers here was
bitten by this a while back :-)

Eg:

my_type_here.xml:
<workflow type="my_type_here">
  ...
</workflow>

my_type_here_action.xml:
<action>
  <type>my_type_here</type>
  ...
</action>

Etc.

Then things should work as expected. The hash key is the workflow type
from memory which defaults to 'default' if not set.

Cheers,

Andrew

[Perl-workflow-devel] Can't get grouped actions

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

Hi everyone,

Recently, I updated workflow 0.31 to 1.32 and I faced with one problem
in my system. Links that were connected to actions disappeared. I
didn't have much time to go deep into debugging, but here is what I
found for now.

I retrieve actions with get_current_actions($group) function.
It refers to get_available_action_names($self,$group), which is in State.pm
I analyzed that function, and I found that
my $action_group = FACTORY->{_action_config}{$action_name}{'group'};
returns nothing.
So, I looked at FACTORY->{_action_config} and found out that all
actions are under 'default' key. I added that key:
my $action_group = FACTORY->{_action_config}{'default'}{$action_name}{'group'};
And my action links returned on the screen.

I don't know why this default key appeared. Can anyone explain this?

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