Thread: [Perl-workflow-devel] Making activity configs local to workflow/state?
Brought to you by:
jonasbn
Menu
▾
▴
perl-workflow-devel
|
From: Alexander K. <ak-...@cy...> - 2007-11-21 09:56:46
|
Hi all,
I've been stumbling over the fact that activity names are global
a lot lately. For example, we have different workflows that have
activities with the same name that should actually do different
things.
IMHO, activity names should be local to their workflow and (maybe?)
even their state. What do you all think about it and if you agree
with me, how would we go on to change the behaviour (possibly while
still being backwards-compatible)?
Best regards,
Alex
--
Dipl.-Math. Alexander Klink | IT-Security Engineer
ak-...@cy... | working @ urn:oid:1.3.6.1.4.1.11417
|
|
From: jonasbn <jo...@gm...> - 2007-11-27 08:48:10
|
Hi Alex, I understand and acknowledge the problem and I think it can be fixed. But I am concerned about backwards compatibility. So perhaps the Workflow configuration should support local and global activities? What do you think? jonasbn -- AIM: BjonasN Gtalk: jo...@gm... ICQ: 62401545 MSN: jo...@io... On 21/11/2007, at 10.56, Alexander Klink wrote: > Hi all, > > I've been stumbling over the fact that activity names are global > a lot lately. For example, we have different workflows that have > activities with the same name that should actually do different > things. > IMHO, activity names should be local to their workflow and (maybe?) > even their state. What do you all think about it and if you agree > with me, how would we go on to change the behaviour (possibly while > still being backwards-compatible)? > > Best regards, > Alex > -- > Dipl.-Math. Alexander Klink | IT-Security Engineer > ak-...@cy... | working @ urn:oid:1.3.6.1.4.1.11417 > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Perl-workflow-devel mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel |
|
From: Alexander K. <a....@cy...> - 2007-11-27 10:24:26
|
Hi Jonas,
On Tue, Nov 27, 2007 at 09:47:58AM +0100, jonasbn wrote:
> I understand and acknowledge the problem and I think it can be fixed.
Fine :-)
> But I am concerned about backwards compatibility.
>
> So perhaps the Workflow configuration should support local and global
> activities?
>
> What do you think?
Sounds reasonable. Maybe we can do inline configuration of action
and conditions (I'd assume they have the same problem?) as the
local method, which would leave it backwards compatible to the old
version. Example:
Old (still valid):
<state name="CREATED" autorun="yes">
<action name="null"
resulting_state="SERVER_KEY_GENERATION">
<condition name="server_key_generation"/>
</action>
<action name="notify_user_of_creation"
resulting_state="PENDING">
<condition name="!server_key_generation"/>
</action>
</state>
New:
<state name="CREATED" autorun="yes">
<action name="null"
resulting_state="SERVER_KEY_GENERATION"
class="Workflow::Action::Null">
<condition name="server_key_generation"
class="OpenXPKI::Server::Workflow::Condition::IsServerKeyGeneration"/>
</action>
<action name="notify_user_of_creation"
resulting_state="PENDING"
class="OpenXPKI::Server::Workflow::Activity::Tools::Notification"
message="csr_created">
<condition name="!server_key_generation"/>
</action>
</state>
Hmmm, on second thought, this does not really increase the readability
of the config file - anyone with a better idea?
Best regards,
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
|
|
From: jonasbn <jo...@gm...> - 2007-12-03 21:39:05
|
Hi Alex, The readibility of the XML files are not that good anyway, I am not =20 saying we should not attempt to improve this, but your suggestions are =20= valid in my eyes. jonasbn -- AIM: BjonasN Gtalk: jo...@gm... ICQ: 62401545 MSN: jo...@io... On 27/11/2007, at 11.24, Alexander Klink wrote: > Hi Jonas, > > On Tue, Nov 27, 2007 at 09:47:58AM +0100, jonasbn wrote: >> I understand and acknowledge the problem and I think it can be fixed. > Fine :-) > >> But I am concerned about backwards compatibility. >> >> So perhaps the Workflow configuration should support local and global >> activities? >> >> What do you think? > Sounds reasonable. Maybe we can do inline configuration of action > and conditions (I'd assume they have the same problem?) as the > local method, which would leave it backwards compatible to the old > version. Example: > > Old (still valid): > <state name=3D"CREATED" autorun=3D"yes"> > <action name=3D"null" > resulting_state=3D"SERVER_KEY_GENERATION"> > <condition name=3D"server_key_generation"/> > </action> > > <action name=3D"notify_user_of_creation" > resulting_state=3D"PENDING"> > <condition name=3D"!server_key_generation"/> > </action> > </state> > > New: > <state name=3D"CREATED" autorun=3D"yes"> > <action name=3D"null" > resulting_state=3D"SERVER_KEY_GENERATION" > class=3D"Workflow::Action::Null"> > <condition name=3D"server_key_generation" > =20 > class=3D"OpenXPKI::Server::Workflow::Condition::IsServerKeyGeneration"/>= > </action> > > <action name=3D"notify_user_of_creation" > resulting_state=3D"PENDING" > =20 > class=3D"OpenXPKI::Server::Workflow::Activity::Tools::Notification" > message=3D"csr_created"> > <condition name=3D"!server_key_generation"/> > </action> > </state> > > Hmmm, on second thought, this does not really increase the readability > of the config file - anyone with a better idea? > > Best regards, > Alex > --=20 > Dipl.-Math. Alexander Klink | IT-Security Engineer | = a....@cy... > mobile: +49 (0)178 2121703 | Cynops GmbH | = http://www.cynops.de > ----------------------------+----------------------=20 > +--------------------- > HRB 7833, Amtsgericht | USt-Id: DE 213094986 | =20 > Gesch=E4ftsf=FChrer: > Bad Homburg v. d. H=F6he | | Martin =20 > Bartosch |
|
From: Jim B. <cb...@bu...> - 2007-11-27 12:30:44
|
Alexander Klink wrote: > > Hmmm, on second thought, this does not really increase the readability > of the config file - anyone with a better idea? > It does seem odd that you can have multiple workflow.xml files, each with a type, but the remaining config files are not per type. Would it be possible to support a 'global' action.xml, condition.xml, etc., and also allow users to load a 'typed' action.xml? From the config side, the typed version would simply add the <type> tags to the top. Evaluation would first look for a typed definition of an action, if available, then go to the global definition. If not there, error. I haven't looked at the guts, so I'm not sure what would be involved to get this sort of configuration loaded, but this seems useful. There are cases where you might want global actions, and I agree that there are many cases where you want type-specific ones. The same applies to conditions, I think. Jim -- Jim Brandt Administrative Computing Services University at Buffalo |
|
From: jonasbn <jo...@gm...> - 2007-12-03 21:36:38
|
Hi Jim, This is not a bad suggestion at all. I do not think the implementation of the suggested would spoil anything it is more addition that is it changing. I have not made a thorough analysis though. jonasbn -- AIM: BjonasN Gtalk: jo...@gm... ICQ: 62401545 MSN: jo...@io... On 27/11/2007, at 13.30, Jim Brandt wrote: > > > Alexander Klink wrote: > >> Hmmm, on second thought, this does not really increase the >> readability >> of the config file - anyone with a better idea? > > It does seem odd that you can have multiple workflow.xml files, each > with a type, but the remaining config files are not per type. > > Would it be possible to support a 'global' action.xml, > condition.xml, etc., and also allow users to load a 'typed' > action.xml? From the config side, the typed version would simply add > the <type> tags to the top. > > Evaluation would first look for a typed definition of an action, if > available, then go to the global definition. If not there, error. > > I haven't looked at the guts, so I'm not sure what would be involved > to get this sort of configuration loaded, but this seems useful. > There are cases where you might want global actions, and I agree > that there are many cases where you want type-specific ones. The > same applies to conditions, I think. > > > Jim > > -- > Jim Brandt > Administrative Computing Services > University at Buffalo > |
|
From: Jim B. <cb...@bu...> - 2007-12-10 13:52:07
|
jonasbn wrote:
> Hi Jim,
>
> This is not a bad suggestion at all.
>
> I do not think the implementation of the suggested would spoil anything
> it is more addition that is it changing. I have not made a thorough
> analysis though.
>
I took a look and I agree, this shouldn't be too intrusive to implement.
I'm going to spend some time working on it and see how far I get.
Can I work in trunk, or would you prefer to set up a branch?
FYI, I also noticed a few files appear to be missing from the subversion
checkout. Got this when I ran Build on the checkout:
WARNING: the following files are missing in your kit:
Makefile.PL
META.yml
Please inform the author.
Maybe these get generated as part of the CPAN upload?
> jonasbn
> --
> AIM: BjonasN Gtalk: jo...@gm...
> ICQ: 62401545 MSN: jo...@io...
>
>
> On 27/11/2007, at 13.30, Jim Brandt wrote:
>
>>
>>
>> Alexander Klink wrote:
>>
>>> Hmmm, on second thought, this does not really increase the readability
>>> of the config file - anyone with a better idea?
>>
>> It does seem odd that you can have multiple workflow.xml files, each
>> with a type, but the remaining config files are not per type.
>>
>> Would it be possible to support a 'global' action.xml, condition.xml,
>> etc., and also allow users to load a 'typed' action.xml? From the
>> config side, the typed version would simply add the <type> tags to the
>> top.
>>
>> Evaluation would first look for a typed definition of an action, if
>> available, then go to the global definition. If not there, error.
>>
>> I haven't looked at the guts, so I'm not sure what would be involved
>> to get this sort of configuration loaded, but this seems useful. There
>> are cases where you might want global actions, and I agree that there
>> are many cases where you want type-specific ones. The same applies to
>> conditions, I think.
>>
>>
>> Jim
>>
>> --
>> Jim Brandt
>> Administrative Computing Services
>> University at Buffalo
>>
>
--
Jim Brandt
Administrative Computing Services
University at Buffalo
|
|
From: jonasbn <jo...@gm...> - 2007-12-10 14:05:14
|
Hi Jim, Yes these files are generated when building the distribution, so we are not interested in having these under revision control. ./Build dist Should generate them for you, You could work in trunk, but a branch would be preferred if you do not mind. jonasbn -- AIM: BjonasN Gtalk: jo...@gm... ICQ: 62401545 MSN: jo...@io... On 10/12/2007, at 14.52, Jim Brandt wrote: > > > jonasbn wrote: >> Hi Jim, >> This is not a bad suggestion at all. >> I do not think the implementation of the suggested would spoil >> anything it is more addition that is it changing. I have not made a >> thorough analysis though. > > I took a look and I agree, this shouldn't be too intrusive to > implement. > > I'm going to spend some time working on it and see how far I get. > > Can I work in trunk, or would you prefer to set up a branch? > > FYI, I also noticed a few files appear to be missing from the > subversion checkout. Got this when I ran Build on the checkout: > > WARNING: the following files are missing in your kit: > Makefile.PL > META.yml > Please inform the author. > > Maybe these get generated as part of the CPAN upload? > >> jonasbn >> -- >> AIM: BjonasN Gtalk: jo...@gm... >> ICQ: 62401545 MSN: jo...@io... >> On 27/11/2007, at 13.30, Jim Brandt wrote: >>> >>> >>> Alexander Klink wrote: >>> >>>> Hmmm, on second thought, this does not really increase the >>>> readability >>>> of the config file - anyone with a better idea? >>> >>> It does seem odd that you can have multiple workflow.xml files, >>> each with a type, but the remaining config files are not per type. >>> >>> Would it be possible to support a 'global' action.xml, >>> condition.xml, etc., and also allow users to load a 'typed' >>> action.xml? From the config side, the typed version would simply >>> add the <type> tags to the top. >>> >>> Evaluation would first look for a typed definition of an action, >>> if available, then go to the global definition. If not there, error. >>> >>> I haven't looked at the guts, so I'm not sure what would be >>> involved to get this sort of configuration loaded, but this seems >>> useful. There are cases where you might want global actions, and I >>> agree that there are many cases where you want type-specific ones. >>> The same applies to conditions, I think. >>> >>> >>> Jim >>> >>> -- >>> Jim Brandt >>> Administrative Computing Services >>> University at Buffalo >>> > > -- > Jim Brandt > Administrative Computing Services > University at Buffalo > |
×
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