perl-workflow-devel Mailing List for Perl Workflow (Page 9)
Brought to you by:
jonasbn
Menu
▾
▴
perl-workflow-devel — discussion list for developers of Perl Workflow
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(12) |
Feb
|
Mar
(4) |
Apr
|
May
(1) |
Jun
(11) |
Jul
(10) |
Aug
(7) |
Sep
(16) |
Oct
(2) |
Nov
(4) |
Dec
(11) |
| 2008 |
Jan
(1) |
Feb
(1) |
Mar
(9) |
Apr
(19) |
May
(3) |
Jun
(4) |
Jul
|
Aug
(8) |
Sep
(1) |
Oct
(6) |
Nov
(13) |
Dec
(17) |
| 2009 |
Jan
(5) |
Feb
(2) |
Mar
(3) |
Apr
(17) |
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
(14) |
Oct
(2) |
Nov
|
Dec
(13) |
| 2010 |
Jan
(6) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(4) |
Sep
(3) |
Oct
|
Nov
(10) |
Dec
|
| 2011 |
Jan
(8) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(6) |
Nov
(7) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(4) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(4) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jonas B. N. <jo...@gm...> - 2008-04-06 07:49:30
|
Hi Jim, I prefer handling transactions manually too, as I see it would should of course support AutoCommit and non-automatic commits. As for the actual implementation, it would be nice to eliminate possible warnings. jonasbn On 01/04/2008, at 19.41, Jim Brandt wrote: > Hello all, > > We generally avoid using AutoCommit preferring to commit manually when > it makes sense for transactional integrity. That is, you do everything > you need to do for a single transaction, then commit. If something > goes > wrong, you can rollback the entire transaction cleanly. > > Workflow defaults to AutoCommit and I was wondering if there would be > any interest in allowing this to be a passed in parameter. We could > still allow AutoCommit to be set, but we could also put in manual > commits at appropriate points in a transaction. This would result in > some warnings from DBI whan you manually ran the commits (unless we > shielded the commits with a test for AutoCommit). > > Any thoughts one way or the other? > > Thanks, > Jim > > -- > Jim Brandt > Administrative Computing Services > University at Buffalo > > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Perl-workflow-devel mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel |
|
From: Jonas B. N. <jo...@gm...> - 2008-04-06 07:49:30
|
Hello All, I am releasing 0.32_1 now, I have attempted to briefly describe everything that has happened in Changes, but I have not really had time to pay attention to the commit log :-/ 0.32_1 Sun Apr 6 09:02:42 CEST 2008 (update not required) - This is an alpha release introducing typed condition, implemented by Jim Brandt, we are very interested in feedback on this release, so please consider joining the mailing list or send feedback to jo...@cp... directly. - Typed conditions makes it possible for different workflows to hold unique methods for workflow steps even with names coliding. Example workflow foo and bar can have a condition baz, but baz are two different implementations in foo and bar respectively Updated: t/cached_conditions.t t/factory.t t/state.t t/TestUtil.t t/condition.t t/workflow_type.t t/config.t t/workflow.t Workflow Workflow::Factory Workflow::Config Workflow::Config::XML Workflow::Config::Perl Workflow::Action Workflow::State Workflow::Condition Workflow::Persister::DBI Workflow::History Workflow::Persister::SPOPS Introduced t/state_perl.t t/TestApp/Action/TicketCreateType.pm t/TestApp/Condition/HasUserType.pm t/workflow_action_type.perl t/workflow_action_type.xml t/workflow_condition_type.perl t/workflow_condition_type.xml t/workflow_persister.perl t/workflow_persister.xml t/workflow_type.perl t/workflow_type.xml - This release also holds new tests of persister configs, there is however always room for more - time_zone parameter can now be passer around for use by the Workflow DateTime objects internally jonasbn On 31/01/2008, at 15.58, Jim Brandt wrote: > Hello all, > > I've checked in changes for the following: > > * conditions can now be typed, so if you have foo and a bar workflows, > they can implement the condition AdminRequired with the same name, but > different code for each. > > * I applied all the type changes to the perl config. > > Other notes: > > * I decided not to implement types for validators because I couldn't > come up with a case where a validator would vary by type. I mean > 'is_number' or 'is_email_address' should be the same regardless of a > type. > > * The tests for perl configuration were very light, so most of my time > was spent trying to add testing infrastructure for perl configs. > > * There was no testing of persister configs, so I added some. There is > room for more. > > * I discovered that the persister configuration isn't consistent with > the other methods. For example, in the xml, actions look like: > > <actions> > <action> > > But persisters don't have that outer tag level. It would probably be > good to add it at some point, but it would be tricky to do so and not > break things for older installs. > > So if you get a chance, let me know if the new tests work on your > systems. Even better, if you have real workflow systems in a dev area, > let me know if anything is broken there. I'm going to continue testing > on my systems. > > Jim > > > > -- > Jim Brandt > Administrative Computing Services > University at Buffalo > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > 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: Jim B. <cb...@bu...> - 2008-04-01 17:41:51
|
Hello all, We generally avoid using AutoCommit preferring to commit manually when it makes sense for transactional integrity. That is, you do everything you need to do for a single transaction, then commit. If something goes wrong, you can rollback the entire transaction cleanly. Workflow defaults to AutoCommit and I was wondering if there would be any interest in allowing this to be a passed in parameter. We could still allow AutoCommit to be set, but we could also put in manual commits at appropriate points in a transaction. This would result in some warnings from DBI whan you manually ran the commits (unless we shielded the commits with a test for AutoCommit). Any thoughts one way or the other? Thanks, Jim -- Jim Brandt Administrative Computing Services University at Buffalo |
|
From: Jim B. <cb...@bu...> - 2008-03-26 12:01:06
|
Jonas Brømsø Nielsen wrote: > Hi Jim, > > We (my family) are currently moving apartments, so I do not have a lot > time currently. I will see if I can get the alpha release at the > begining of next week the latest. > Sounds good. Good luck with the move. :) Jim -- Jim Brandt Administrative Computing Services University at Buffalo |
|
From: Jonas B. N. <jo...@gm...> - 2008-03-25 20:48:45
|
Hi Jim, We (my family) are currently moving apartments, so I do not have a lot time currently. I will see if I can get the alpha release at the begining of next week the latest. jonasbn On 25/03/2008, at 15.28, Jim Brandt wrote: > Any thoughts on when you might be able to work on the alpha release? > > Not nagging, just wondering. :) > > Thanks, > Jim > > > Jim Brandt wrote: >> Jonas Brømsø Nielsen wrote: >>> I have never used alpha releases before, I have however considered >>> it for Workflow for a long time, since a lot of people are using >>> it in production. >>> >>> I say we try it out, see some testers feedback and then make an >>> official release. Just to try out this new release strategy. >>> >> Sounds good to me. >> Jim > > -- > Jim Brandt > Administrative Computing Services > University at Buffalo > |
|
From: Jim B. <cb...@bu...> - 2008-03-25 14:29:12
|
Any thoughts on when you might be able to work on the alpha release? Not nagging, just wondering. :) Thanks, Jim Jim Brandt wrote: > Jonas Brømsø Nielsen wrote: > >> I have never used alpha releases before, I have however considered it >> for Workflow for a long time, since a lot of people are using it in >> production. >> >> I say we try it out, see some testers feedback and then make an official >> release. Just to try out this new release strategy. >> > > Sounds good to me. > > Jim > -- Jim Brandt Administrative Computing Services University at Buffalo |
|
From: Jim B. <cb...@bu...> - 2008-03-19 12:17:13
|
Jonas Brømsø Nielsen wrote: > > I have never used alpha releases before, I have however considered it > for Workflow for a long time, since a lot of people are using it in > production. > > I say we try it out, see some testers feedback and then make an official > release. Just to try out this new release strategy. > Sounds good to me. Jim -- Jim Brandt Administrative Computing Services University at Buffalo |
|
From: Jonas B. N. <jo...@gm...> - 2008-03-18 22:20:37
|
On 18/03/2008, at 12.53, Jim Brandt wrote: > > Jonas Brømsø Nielsen wrote: >> Hi Jim, >> And others, I can do a release - do you want it to be an alpha >> release, we have not used this earlier, but if you want to it is >> certainly possible. > > We could do an alpha release. That would imply that some people > would download and test that release and maybe give feedback before > we promoted it. Any feeling on whether that would happen? I know I > could try the alpha release and that would confirm that the CPAN > version matches what I'm testing now (and I didn't sneak something > into my test version). > > How long would we leave it in alpha? > I have never used alpha releases before, I have however considered it for Workflow for a long time, since a lot of people are using it in production. I say we try it out, see some testers feedback and then make an official release. Just to try out this new release strategy. jonasbn >> jonasbn >> On 17/03/2008, at 13.18, Jim Brandt wrote: >>> Has anyone had a chance to try any of the new functionality? >>> >>> We've been running it in our dev and QA environments and so far >>> everything appears to be working correctly. >>> >>> Any chance we could look at a plan to release to CPAN? >>> >>> Thanks, >>> Jim >>> >>> Jim Brandt wrote: >>>> Hello all, >>>> >>>> I've checked in changes for the following: >>>> >>>> * conditions can now be typed, so if you have foo and a bar >>>> workflows, >>>> they can implement the condition AdminRequired with the same >>>> name, but >>>> different code for each. >>>> >>>> * I applied all the type changes to the perl config. >>>> >>>> Other notes: >>>> >>>> * I decided not to implement types for validators because I >>>> couldn't >>>> come up with a case where a validator would vary by type. I mean >>>> 'is_number' or 'is_email_address' should be the same regardless >>>> of a type. >>>> >>>> * The tests for perl configuration were very light, so most of my >>>> time >>>> was spent trying to add testing infrastructure for perl configs. >>>> >>>> * There was no testing of persister configs, so I added some. >>>> There is >>>> room for more. >>>> >>>> * I discovered that the persister configuration isn't consistent >>>> with >>>> the other methods. For example, in the xml, actions look like: >>>> >>>> <actions> >>>> <action> >>>> >>>> But persisters don't have that outer tag level. It would probably >>>> be >>>> good to add it at some point, but it would be tricky to do so and >>>> not >>>> break things for older installs. >>>> >>>> So if you get a chance, let me know if the new tests work on your >>>> systems. Even better, if you have real workflow systems in a dev >>>> area, >>>> let me know if anything is broken there. I'm going to continue >>>> testing >>>> on my systems. >>>> >>>> Jim >>>> >>>> >>>> >>> >>> -- >>> Jim Brandt >>> Administrative Computing Services >>> University at Buffalo >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> 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 > > -- > Jim Brandt > Administrative Computing Services > University at Buffalo > |
|
From: Jim B. <cb...@bu...> - 2008-03-18 11:53:36
|
Jonas Brømsø Nielsen wrote: > Hi Jim, > > And others, I can do a release - do you want it to be an alpha release, > we have not used this earlier, but if you want to it is certainly possible. > We could do an alpha release. That would imply that some people would download and test that release and maybe give feedback before we promoted it. Any feeling on whether that would happen? I know I could try the alpha release and that would confirm that the CPAN version matches what I'm testing now (and I didn't sneak something into my test version). How long would we leave it in alpha? > jonasbn > > On 17/03/2008, at 13.18, Jim Brandt wrote: > >> Has anyone had a chance to try any of the new functionality? >> >> We've been running it in our dev and QA environments and so far >> everything appears to be working correctly. >> >> Any chance we could look at a plan to release to CPAN? >> >> Thanks, >> Jim >> >> Jim Brandt wrote: >>> Hello all, >>> >>> I've checked in changes for the following: >>> >>> * conditions can now be typed, so if you have foo and a bar workflows, >>> they can implement the condition AdminRequired with the same name, but >>> different code for each. >>> >>> * I applied all the type changes to the perl config. >>> >>> Other notes: >>> >>> * I decided not to implement types for validators because I couldn't >>> come up with a case where a validator would vary by type. I mean >>> 'is_number' or 'is_email_address' should be the same regardless of a >>> type. >>> >>> * The tests for perl configuration were very light, so most of my time >>> was spent trying to add testing infrastructure for perl configs. >>> >>> * There was no testing of persister configs, so I added some. There is >>> room for more. >>> >>> * I discovered that the persister configuration isn't consistent with >>> the other methods. For example, in the xml, actions look like: >>> >>> <actions> >>> <action> >>> >>> But persisters don't have that outer tag level. It would probably be >>> good to add it at some point, but it would be tricky to do so and not >>> break things for older installs. >>> >>> So if you get a chance, let me know if the new tests work on your >>> systems. Even better, if you have real workflow systems in a dev area, >>> let me know if anything is broken there. I'm going to continue testing >>> on my systems. >>> >>> Jim >>> >>> >>> >> >> -- >> Jim Brandt >> Administrative Computing Services >> University at Buffalo >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> 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 > -- Jim Brandt Administrative Computing Services University at Buffalo |
|
From: Jonas B. N. <jo...@gm...> - 2008-03-17 19:32:00
|
Hi Jim, And others, I can do a release - do you want it to be an alpha release, we have not used this earlier, but if you want to it is certainly possible. jonasbn On 17/03/2008, at 13.18, Jim Brandt wrote: > Has anyone had a chance to try any of the new functionality? > > We've been running it in our dev and QA environments and so far > everything appears to be working correctly. > > Any chance we could look at a plan to release to CPAN? > > Thanks, > Jim > > Jim Brandt wrote: >> Hello all, >> >> I've checked in changes for the following: >> >> * conditions can now be typed, so if you have foo and a bar >> workflows, >> they can implement the condition AdminRequired with the same name, >> but >> different code for each. >> >> * I applied all the type changes to the perl config. >> >> Other notes: >> >> * I decided not to implement types for validators because I couldn't >> come up with a case where a validator would vary by type. I mean >> 'is_number' or 'is_email_address' should be the same regardless of >> a type. >> >> * The tests for perl configuration were very light, so most of my >> time >> was spent trying to add testing infrastructure for perl configs. >> >> * There was no testing of persister configs, so I added some. There >> is >> room for more. >> >> * I discovered that the persister configuration isn't consistent with >> the other methods. For example, in the xml, actions look like: >> >> <actions> >> <action> >> >> But persisters don't have that outer tag level. It would probably be >> good to add it at some point, but it would be tricky to do so and not >> break things for older installs. >> >> So if you get a chance, let me know if the new tests work on your >> systems. Even better, if you have real workflow systems in a dev >> area, >> let me know if anything is broken there. I'm going to continue >> testing >> on my systems. >> >> Jim >> >> >> > > -- > Jim Brandt > Administrative Computing Services > University at Buffalo > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > 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. <ak-...@cy...> - 2008-03-17 12:35:12
|
Hi Jim,
On Mon, Mar 17, 2008 at 08:18:32AM -0400, Jim Brandt wrote:
> Has anyone had a chance to try any of the new functionality?
Sorry, still on my TODO list, but I hope I can find some time to
try it out soonish ...
Cheers,
Alex
--
Dipl.-Math. Alexander Klink | IT-Security Engineer
ak-...@cy... | working @ urn:oid:1.3.6.1.4.1.11417
|
|
From: Jim B. <cb...@bu...> - 2008-03-17 12:19:43
|
Has anyone had a chance to try any of the new functionality? We've been running it in our dev and QA environments and so far everything appears to be working correctly. Any chance we could look at a plan to release to CPAN? Thanks, Jim Jim Brandt wrote: > Hello all, > > I've checked in changes for the following: > > * conditions can now be typed, so if you have foo and a bar workflows, > they can implement the condition AdminRequired with the same name, but > different code for each. > > * I applied all the type changes to the perl config. > > Other notes: > > * I decided not to implement types for validators because I couldn't > come up with a case where a validator would vary by type. I mean > 'is_number' or 'is_email_address' should be the same regardless of a type. > > * The tests for perl configuration were very light, so most of my time > was spent trying to add testing infrastructure for perl configs. > > * There was no testing of persister configs, so I added some. There is > room for more. > > * I discovered that the persister configuration isn't consistent with > the other methods. For example, in the xml, actions look like: > > <actions> > <action> > > But persisters don't have that outer tag level. It would probably be > good to add it at some point, but it would be tricky to do so and not > break things for older installs. > > So if you get a chance, let me know if the new tests work on your > systems. Even better, if you have real workflow systems in a dev area, > let me know if anything is broken there. I'm going to continue testing > on my systems. > > Jim > > > -- Jim Brandt Administrative Computing Services University at Buffalo |
|
From: Jim B. <cb...@bu...> - 2008-02-29 13:11:08
|
Hello all, We wanted to be able to set a local timezone for all dates for workflow and it currently defaults to GMT, so I added an option for the main workflow.xml file to allow you to pass in a time_zone. The valid values are the timezones you can pass to a DateTime object. If anyone wants to test, I'm working in this branch: http://perl-workflow.svn.sourceforge.net/viewvc/perl-workflow/branches/config_types/ Currently all of the workflow tests pass for me and I'll be testing with our workflow application in development in the next week or so. Thanks, Jim -- Jim Brandt Administrative Computing Services University at Buffalo |
|
From: Jim B. <cb...@bu...> - 2008-01-31 14:58:47
|
Hello all, I've checked in changes for the following: * conditions can now be typed, so if you have foo and a bar workflows, they can implement the condition AdminRequired with the same name, but different code for each. * I applied all the type changes to the perl config. Other notes: * I decided not to implement types for validators because I couldn't come up with a case where a validator would vary by type. I mean 'is_number' or 'is_email_address' should be the same regardless of a type. * The tests for perl configuration were very light, so most of my time was spent trying to add testing infrastructure for perl configs. * There was no testing of persister configs, so I added some. There is room for more. * I discovered that the persister configuration isn't consistent with the other methods. For example, in the xml, actions look like: <actions> <action> But persisters don't have that outer tag level. It would probably be good to add it at some point, but it would be tricky to do so and not break things for older installs. So if you get a chance, let me know if the new tests work on your systems. Even better, if you have real workflow systems in a dev area, let me know if anything is broken there. I'm going to continue testing on my systems. Jim -- Jim Brandt Administrative Computing Services University at Buffalo |
|
From: Jim B. <cb...@bu...> - 2007-12-14 12:38:15
|
Alexander Klink wrote: > Hi Jim, > > On Thu, Dec 13, 2007 at 09:52:09AM -0500, Jim Brandt wrote: >> I've got a working version of workflow that allows you to have typed >> actions in this branch: >> >> http://perl-workflow.svn.sourceforge.net/viewvc/perl-workflow/branches/config_types/ > Well, thanks from me to for now. Unfortunately, I guess I won't have > the time to look at it today - so it will have to wait until next year > :-/ But I'll definitely have a look at it then, being the one who > requested the feature in the first place ;-) > We needed it too, so I was helping myself as well. :) >> * I only put the fix in for the XML configuration. Should I go ahead and >> do the same for the Perl config? > I'd say yes, we should keep it consistent. Yeah, that's what I figured, but I wasn't sure if anyone was using the Perl config. > >> * Has anyone written their own custom config? I'm not sure if these >> changes will work seamlessly with custom sub-classed configuration methods. > Is that even possible? I'd guess it suffers from the same sub-classing > problems that are all over the place. I doubt it, but maybe we should add a bit warning in the Changes that these change might break a sub-classed config if you had one. > >> * Would anyone want this same functionality for conditions or validators? > I guess it'd be useful for conditions for us, we don't have too many > validators. All in all, I'd say it would probably be useful and most > consistent if it was present for all types. Yep, I agree here too. I'll take a look at these. I think the changes will be similar. The tough part is coming up with all the new tests. > > Merry christmas and a happy new year :-) > Alex Indeed, happy holidays to all! :) Jim -- Jim Brandt Administrative Computing Services University at Buffalo |
|
From: Jim B. <cb...@bu...> - 2007-12-14 12:34:41
|
As much as I'd like to, I won't be there in person. But I'll watch the conference wiki for the time of the BOF and I could try to attend virtually if someone would host me via iChat (voice or video) in the meeting. Jim jonasbn wrote: > Hello All, > > This is completely off topic, but I would like to ask if any of you > plan to participate at YAPC::Europe 2008 in Copenhagen, I am in the > organizing team, so I will be there, but I would love to meet with as > many of you as possible face to face to discuss the future of Workflow. > > Let me know if you are planning to come, > > Merry christmas, > > jonasbn > -- > AIM: BjonasN Gtalk: jo...@gm... > ICQ: 62401545 MSN: jo...@io... > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > 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: Alexander K. <ak-...@cy...> - 2007-12-14 09:57:41
|
Hi Jim, On Thu, Dec 13, 2007 at 09:52:09AM -0500, Jim Brandt wrote: > I've got a working version of workflow that allows you to have typed > actions in this branch: > > http://perl-workflow.svn.sourceforge.net/viewvc/perl-workflow/branches/config_types/ Well, thanks from me to for now. Unfortunately, I guess I won't have the time to look at it today - so it will have to wait until next year :-/ But I'll definitely have a look at it then, being the one who requested the feature in the first place ;-) > * I only put the fix in for the XML configuration. Should I go ahead and > do the same for the Perl config? I'd say yes, we should keep it consistent. > * Has anyone written their own custom config? I'm not sure if these > changes will work seamlessly with custom sub-classed configuration methods. Is that even possible? I'd guess it suffers from the same sub-classing problems that are all over the place. > * Would anyone want this same functionality for conditions or validators? I guess it'd be useful for conditions for us, we don't have too many validators. All in all, I'd say it would probably be useful and most consistent if it was present for all types. Merry christmas and a happy new year :-) Alex -- Dipl.-Math. Alexander Klink | IT-Security Engineer ak-...@cy... | working @ urn:oid:1.3.6.1.4.1.11417 |
|
From: Alexander K. <ak-...@cy...> - 2007-12-14 09:51:02
|
Hi Jonas,
On Fri, Dec 14, 2007 at 10:41:47AM +0100, jonasbn wrote:
> This is completely off topic, but I would like to ask if any of you
> plan to participate at YAPC::Europe 2008 in Copenhagen, I am in the
> organizing team, so I will be there, but I would love to meet with as
I know, I do read your blog ;-)
> many of you as possible face to face to discuss the future of Workflow.
> Let me know if you are planning to come,
I've been thinking about attending and I guess if I can fit it in, I'll
be there. Sounds fun to meet (all of) you in person to me as well.
> Merry christmas,
Merry christmas to you too ...
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-12-14 09:41:50
|
Hello All, This is completely off topic, but I would like to ask if any of you plan to participate at YAPC::Europe 2008 in Copenhagen, I am in the organizing team, so I will be there, but I would love to meet with as many of you as possible face to face to discuss the future of Workflow. Let me know if you are planning to come, Merry christmas, jonasbn -- AIM: BjonasN Gtalk: jo...@gm... ICQ: 62401545 MSN: jo...@io... |
|
From: jonasbn <jo...@gm...> - 2007-12-14 09:39:29
|
Hej Jim, Excellent, I will have a look at the code and docs and get back to you. Thanks for the contribution and merry christmas, jonasbn -- AIM: BjonasN Gtalk: jo...@gm... ICQ: 62401545 MSN: jo...@io... On 13/12/2007, at 15.52, Jim Brandt wrote: > Hello all, > > I've got a working version of workflow that allows you to have typed > actions in this branch: > > http://perl-workflow.svn.sourceforge.net/viewvc/perl-workflow/branches/config_types/ > > I'd call it beta at this point. > > I've got all tests passing for me except for the SPOPS and Data::UUID > tests, which get skipped because I don't have the modules installed. > This version also works with our workflow engine where we have the > problem of actions with the same names but different types. > > Some notes: > > * I added the new docs to the Workflow::Action module since it seemed > most appropriate. Please take a look and see if the docs make sense. > > * I didn't do anything with version numbers. Should I bump them in all > of the individual modules? > > * I only put the fix in for the XML configuration. Should I go ahead > and > do the same for the Perl config? > > * Has anyone written their own custom config? I'm not sure if these > changes will work seamlessly with custom sub-classed configuration > methods. > > * Would anyone want this same functionality for conditions or > validators? > > * Anything else I've forgotten? > > As an aside, does anyone have any ideas on ways to change the way the > TestUtil.pm module works? It plays some games with cwd and that messes > with the prove utility when you're trying to run tests. So I end up > having to put a 'use lib' in the top to point to my working directory, > but I'd like to not have to do that. > > Thanks for any feedback. > Jim > > > > -- > Jim Brandt > Administrative Computing Services > University at Buffalo > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Perl-workflow-devel mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel |
|
From: Jim B. <cb...@bu...> - 2007-12-13 14:52:20
|
Hello all, I've got a working version of workflow that allows you to have typed actions in this branch: http://perl-workflow.svn.sourceforge.net/viewvc/perl-workflow/branches/config_types/ I'd call it beta at this point. I've got all tests passing for me except for the SPOPS and Data::UUID tests, which get skipped because I don't have the modules installed. This version also works with our workflow engine where we have the problem of actions with the same names but different types. Some notes: * I added the new docs to the Workflow::Action module since it seemed most appropriate. Please take a look and see if the docs make sense. * I didn't do anything with version numbers. Should I bump them in all of the individual modules? * I only put the fix in for the XML configuration. Should I go ahead and do the same for the Perl config? * Has anyone written their own custom config? I'm not sure if these changes will work seamlessly with custom sub-classed configuration methods. * Would anyone want this same functionality for conditions or validators? * Anything else I've forgotten? As an aside, does anyone have any ideas on ways to change the way the TestUtil.pm module works? It plays some games with cwd and that messes with the prove utility when you're trying to run tests. So I end up having to put a 'use lib' in the top to point to my working directory, but I'd like to not have to do that. Thanks for any feedback. Jim -- 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 > |
|
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-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: 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 > |
