ruote tmp/log_2012-01-25.html

2012-01-25 08:25:33 utc jmettraux Skippy1: hello, sorry I was breakfasting earlier on, only saw your question when you were already away
2012-01-25 08:27:12 utc jmettraux could help
2012-01-25 08:37:35 utc Skippy1 Is there no way to handle that inside the participants themselves? Like in a a delayed_job manner? I'm writing participants for use in processes that will be written by external users and I don't want them worrying about error handling if I can take care of it transparently for them. Otherwise I'm going to have to modify the process after they have defined it and attach on_error expressions to it
2012-01-25 08:38:25 utc jmettraux the delayed_job pattern you're mentioning feels external to me
2012-01-25 08:38:37 utc jmettraux inside the participant you're free to catch errors at will
2012-01-25 08:40:29 utc Skippy1 true I guess I could just put everything inside a begin/rescue/end block
2012-01-25 08:41:25 utc Skippy1 can you terminate a process from within a participant?
2012-01-25 08:41:51 utc jmettraux from a "local participant" yes
2012-01-25 08:42:00 utc jmettraux let me cook a gist of that
2012-01-25 08:44:33 utc Skippy1 I should have access to the engine from within the participant so I guess it's as easy as calling cancel_process
2012-01-25 08:44:42 utc jmettraux yes
2012-01-25 08:46:13 utc jmettraux (basically)
2012-01-25 08:49:53 utc Skippy1 is on_workitem a hook?
2012-01-25 08:54:57 utc jmettraux before ruote 2.3.0 (master), it was consume(workitem), lately (ruote 2.3.0 to be released soon), I started pushing on_workitem
2012-01-25 08:55:17 utc jmettraux it reminds of people that participants are some kind of hook in a process instance
2012-01-25 08:55:59 utc jmettraux people were looking at consume(workitem) and then asking me, can I add a hook that is called each time a workitem comes in ?
2012-01-25 08:56:18 utc jmettraux and I was saying, come on, can't you see that consume(workitem) is called each time
2012-01-25 08:57:05 utc Skippy1 haha yess
2012-01-25 08:57:33 utc Skippy1 I guess people are thinking of a before_consume/consume/after_consume model
2012-01-25 08:57:40 utc Skippy1 like in Rails with it's filters
2012-01-25 08:58:19 utc jmettraux yes, I see lots of people with Rails hardwired brains
2012-01-25 08:59:04 utc Skippy1 I'm developing with 2.3.0 from git and consume is still working... when will it be deprecated?
2012-01-25 08:59:24 utc jmettraux in one or two years
2012-01-25 08:59:38 utc jmettraux or maybe never, so that old examples are still ok
2012-01-25 09:00:55 utc Skippy1 cool