| 2011-02-21 03:37:08 utc | jmettraux | fireofenigma: hello and welcome to #ruote |
| 2011-02-21 03:37:48 utc | fireofenigma | been checking out ruote, reading the docs, and downloading the sample rails-apps. |
| 2011-02-21 03:38:24 utc | fireofenigma | one thing that i'm trying to figure out, not sure if i'm missing something, but trying to figure out how the ruote fits in a rails app. |
| 2011-02-21 03:39:04 utc | jmettraux | fits in which sense ? |
| 2011-02-21 03:39:13 utc | fireofenigma | say you have a sales workflow, you have models and controllers to create and update sales. |
| 2011-02-21 03:39:35 utc | fireofenigma | Sales go thru states like new, pending, in review, approved, live, archived, etc. |
| 2011-02-21 03:39:49 utc | jmettraux | so you have a "sales" object ? |
| 2011-02-21 03:40:05 utc | fireofenigma | and depending on what state it's in, someone of a particular role is in charge of updating the sale |
| 2011-02-21 03:40:07 utc | fireofenigma | yes |
| 2011-02-21 03:40:27 utc | fireofenigma | I would specify the participants in the workflow process definition. |
| 2011-02-21 03:40:44 utc | fireofenigma | But how does that relate to the actual people who will be reviewing/udpating the sales isntances? |
| 2011-02-21 03:40:54 utc | jmettraux | it depends |
| 2011-02-21 03:41:19 utc | jmettraux | either you map participant names one to one with user names |
| 2011-02-21 03:41:21 utc | fireofenigma | My initial thought was in the view, I look at the work item and see which participant has it. |
| 2011-02-21 03:41:43 utc | jmettraux | either you have some logic that maps participant names to user names |
| 2011-02-21 03:42:00 utc | jmettraux | in short, you have to decide if your participant are roles or users |
| 2011-02-21 03:42:13 utc | fireofenigma | the part i think i understand |
| 2011-02-21 03:43:17 utc | fireofenigma | where i grapple with is, all the logic to update the sale (the actual actions so that the work item can proceed to the next step/express) will be copmletely in my model |
| 2011-02-21 03:43:25 utc | fireofenigma | s/controllers? |
| 2011-02-21 03:44:04 utc | jmettraux | usually you have two kind of participants, human or automated |
| 2011-02-21 03:44:06 utc | fireofenigma | So in essence, I'm using the workflow engine to control/manage what state the sale is in the workflow? |
| 2011-02-21 03:44:33 utc | jmettraux | you use the workflow engine to orchestrate the state of your models |
| 2011-02-21 03:44:46 utc | jmettraux | or simply to circulate tasks among participants |
| 2011-02-21 03:44:54 utc | jmettraux | a human participant would update some workitem fields |
| 2011-02-21 03:45:10 utc | jmettraux | an automated participant would change the state of some models based on workitem fields |
| 2011-02-21 03:45:30 utc | jmettraux | of course, an automated participant can modify the the workitem fields as well |
| 2011-02-21 03:47:23 utc | fireofenigma | that's where my thought is, which brings me to a question i have on what's a good way to analyze the problem to determine whether it's sipmler to use a state machine or workflow |
| 2011-02-21 03:48:04 utc | jmettraux | well, it seems your mindset is state machine tuned |
| 2011-02-21 03:49:55 utc | jmettraux | it's always simpler to use a state machine, but most of them are 1 state 1 resource |
| 2011-02-21 03:50:06 utc | jmettraux | they're great for lifecycles and protocols |
| 2011-02-21 03:50:12 utc | jmettraux | and they are great for limited workflows |
| 2011-02-21 03:50:35 utc | jmettraux | a workflow engine is just like an interpreter |
| 2011-02-21 03:50:44 utc | jmettraux | it takes a program and runs it |
| 2011-02-21 03:51:00 utc | jmettraux | and that program can change the state of multiple things |
| 2011-02-21 03:51:04 utc | jmettraux | a state machine is reactive |
| 2011-02-21 03:51:22 utc | jmettraux | you change the state of a thing and possibly, transitions do fire |
| 2011-02-21 03:51:37 utc | jmettraux | a state machine is declarative, a workflow is imperative |
| 2011-02-21 03:57:29 utc | fireofenigma | thanks for the explanation, gives me a starting point to frame my particular situation |
| 2011-02-21 03:59:02 utc | fireofenigma | one other question is--for 'typical' sales worfklow, do people tend to implement these as state machine or as workflow? |
| 2011-02-21 03:59:16 utc | fireofenigma | or is such generalization possible? |
| 2011-02-21 03:59:44 utc | jmettraux | it depends on the technical sophistication of the implementers |
| 2011-02-21 03:59:53 utc | jmettraux | it depends on how does the workflow change |
| 2011-02-21 04:00:13 utc | jmettraux | for a tiny rails app, frankly, go with a state machine |
| 2011-02-21 04:00:21 utc | jmettraux | but don't call that a workflow |
| 2011-02-21 04:00:29 utc | jmettraux | it's more of a |
| 2011-02-21 04:00:35 utc | jmettraux | "sales case lifecycle" |
| 2011-02-21 04:01:25 utc | jmettraux | sometimes it maps one to one with a workflow |
| 2011-02-21 04:01:26 utc | jmettraux | sometimes not |
| 2011-02-21 04:01:54 utc | jmettraux | when it changes for "it maps" to "it doesn't map", it means work (for the developer) |
| 2011-02-21 04:02:38 utc | jmettraux | if ruote appears too complicated to you, please don't use it |
| 2011-02-21 04:03:58 utc | jmettraux | if it's a one shot rails application that'll you leave behind with the next customer, then use a state machine |
| 2011-02-21 10:36:22 utc | tosch_le | jmettraux: hello! |
| 2011-02-21 10:36:57 utc | tosch_le | had a look an ruote-on-rails together with v2.2.0 |
| 2011-02-21 10:37:43 utc | tosch_le | there was just a minor problem in the definition model (Ruote::Parser vs. Ruote::Reader), but i could solve that quickly |
| 2011-02-21 10:38:35 utc | jmettraux | hello, excellent news ! |
| 2011-02-21 10:38:41 utc | jmettraux | many thanks ! |
| 2011-02-21 10:40:25 utc | tosch_le | did an update to rails 3.0.4 as well |
| 2011-02-21 10:40:34 utc | tosch_le | it was a pleasure, as always. |
| 2011-02-21 10:42:36 utc | jmettraux | oh, that's great |
| 2011-02-21 10:57:35 utc | jmettraux | tosch_le: how's the new job going ? Liking it ? |
| 2011-02-21 10:58:00 utc | tosch_le | yeah, it's great. |
| 2011-02-21 10:58:37 utc | tosch_le | having a lot of fun here. |
| 2011-02-21 10:59:15 utc | tosch_le | one drawback, though: no need for ruote[-kit] until now |
| 2011-02-21 10:59:22 utc | tosch_le | ;-) |
| 2011-02-21 10:59:56 utc | tosch_le | but i successfully suggested to use rufus-scheduler for our app |
| 2011-02-21 11:00:05 utc | jmettraux | oh nice |
| 2011-02-21 11:01:03 utc | jmettraux | I'd be unhappy if you told me you forced ruote[kit] into your company |
| 2011-02-21 11:02:16 utc | tosch_le | never would do that. always use the appropriate tools, that's the motto. |
| 2011-02-21 11:09:55 utc | jmettraux | tosch_le: how goes the new look of ruote-on-rails ? No glitches ? |
| 2011-02-21 11:11:07 utc | tosch_le | no, it looks great. |
| 2011-02-21 11:13:27 utc | jmettraux | thanks :-) |
| 2011-02-21 19:54:22 utc | med_ | Hello |
| 2011-02-21 21:30:12 utc | belucid | hello med_ |