Thread: [Perl-workflow-devel] Can't get grouped actions
Brought to you by:
jonasbn
Menu
▾
▴
perl-workflow-devel
|
From: Ivan P. <iva...@gm...> - 2009-03-01 23:37:08
|
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...
|
|
From: Andrew O'B. <an...@or...> - 2009-03-02 05:24:07
|
> 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
|
|
From: Ivan P. <iva...@gm...> - 2009-04-25 07:39:58
|
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...
|
|
From: Andrew O'B. <an...@or...> - 2009-04-26 23:53:19
|
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...
>
>
|
|
From: Jim B. <cb...@bu...> - 2009-04-27 12:36:35
|
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 - New Free Runtime and 30 Day Trial > Check out the new simplified licensign option that enables unlimited > royalty-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 |
|
From: Ivan P. <iva...@gm...> - 2009-04-27 21:03:49
|
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...
|
|
From: Jonas B. N. <jo...@gm...> - 2009-04-27 21:15:11
|
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 - New Free Runtime and 30 Day Trial
> Check out the new simplified licensign option that enables unlimited
> royalty-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
|
|
From: Ivan P. <iva...@gm...> - 2009-04-27 21:25:02
|
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... |
|
From: Jonas B. N. <jo...@gm...> - 2009-04-27 21:30:12
|
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... > |
|
From: Jonas B. N. <jo...@gm...> - 2009-06-15 20:43:27
|
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... > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X