| 2010-11-05 01:31:44 utc | fixr | hello everyone! |
| 2010-11-05 01:35:56 utc | jmettraux | fixr: hello ! |
| 2010-11-05 01:36:32 utc | fixr | jmettraux: morning! |
| 2010-11-05 01:36:43 utc | jmettraux | how are you doing ? |
| 2010-11-05 01:38:27 utc | fixr | pretty good, thanks! you? |
| 2010-11-05 01:38:38 utc | jmettraux | fine as well, thanks |
| 2010-11-05 01:38:43 utc | fixr | getting cold over Japan? |
| 2010-11-05 01:39:03 utc | jmettraux | yes, I like it |
| 2010-11-05 01:39:12 utc | jmettraux | how about Venezuela ? |
| 2010-11-05 01:39:50 utc | fixr | as warm as ever. We have barely two seasons over here, warm and warmer :) |
| 2010-11-05 01:40:30 utc | jmettraux | humid and raining ? |
| 2010-11-05 01:41:23 utc | fixr | indeed. Altough raining season is almost over (thankfully :)) |
| 2010-11-05 01:42:40 utc | fixr | I wanted to ask you something, if it isn't too much trouble ! |
| 2010-11-05 01:43:24 utc | fixr | I was wondering which operators can be used on a conditional expression, besides equality and greater/less than |
| 2010-11-05 01:43:35 utc | fixr | is it possible to use && and ||? |
| 2010-11-05 01:43:46 utc | jmettraux | not really |
| 2010-11-05 01:43:56 utc | fixr | I think I know the answer (I tried and searched the list), but still wanted to confirm :) |
| 2010-11-05 01:44:07 utc | jmettraux | unless you allow ruby evaluations and do "${r: x || y }" |
| 2010-11-05 01:44:47 utc | fixr | tried that too, couldn't get it to work. I was probably doing something wrong |
| 2010-11-05 01:45:03 utc | fixr | I need to compare many wi fields |
| 2010-11-05 01:45:04 utc | jmettraux | it's disabled by default |
| 2010-11-05 01:45:13 utc | fixr | oh, no, I enabled it |
| 2010-11-05 01:45:19 utc | jmettraux | ok |
| 2010-11-05 01:45:22 utc | fixr | on the FsStorage |
| 2010-11-05 01:45:45 utc | jmettraux | then "${r: wi.fields['x'] || wi.fields['y'] }" or something |
| 2010-11-05 01:46:30 utc | fixr | not sure why it didn't work, but I'll try it like this again |
| 2010-11-05 01:46:55 utc | fixr | I guess nested if's work as well, but it's much cleaner like this |
| 2010-11-05 01:48:37 utc | jmettraux | yes |
| 2010-11-05 01:49:18 utc | jmettraux | another variant would be to wrap the ruby conditional code in a participant that sets a field with the result, and then use that field for a subsquent if |
| 2010-11-05 01:49:27 utc | jmettraux | that fits well "decision" scenarii |
| 2010-11-05 01:51:04 utc | fixr | that's a good option to consider as well! |
| 2010-11-05 01:52:03 utc | fixr | my def's are written by people that don't really know much programming, so I'm trying to keep them simple. Wrapping it on a participant sounds very good |
| 2010-11-05 01:52:47 utc | jmettraux | :-) |
| 2010-11-05 01:55:33 utc | fixr | thank you! |
| 2010-11-05 01:55:43 utc | jmettraux | you're welcome |
| 2010-11-05 01:56:39 utc | fixr | btw, I checked out quaderno. Very nice work, as usual |
| 2010-11-05 01:57:11 utc | jmettraux | ah thanks |
| 2010-11-05 01:57:24 utc | fixr | I remember we once talked about form builders. Unfortunately my schedule has been very complicated lately |
| 2010-11-05 01:57:37 utc | fixr | you should write a post about how you manage to do so much in so little time! |
| 2010-11-05 01:57:50 utc | fixr | I really admire that :) |
| 2010-11-05 01:58:01 utc | jmettraux | well |
| 2010-11-05 01:58:16 utc | jmettraux | it's the urge to unbreak some things |
| 2010-11-05 01:58:46 utc | jmettraux | quaderno is the 4th or 5th iteration of a form thing I've been building |
| 2010-11-05 01:59:10 utc | jmettraux | lots of errors in the past |
| 2010-11-05 01:59:12 utc | fixr | yup. Looks much more polished and refined indeed |
| 2010-11-05 02:00:39 utc | fixr | errors are quite a wonderful thing, when you learn from them :) |
| 2010-11-05 02:00:45 utc | jmettraux | :-) |
| 2010-11-05 03:06:54 utc | fixr | off to bed. Bye! |
| 2010-11-05 10:39:42 utc | jmettraux | skade: hello, welcome to #ruote |
| 2010-11-05 10:40:23 utc | skade | hi, thanks for the welcome :) |
| 2010-11-05 10:42:41 utc | jmettraux | skade: RubyKaigi 2009 IIRC ? |
| 2010-11-05 10:43:00 utc | skade | exactly :) |
| 2010-11-05 10:43:23 utc | jmettraux | cool, I hope you had a good time |
| 2010-11-05 10:43:37 utc | skade | yes, sadly i didn't make it this year |
| 2010-11-05 10:44:07 utc | skade | i have to make it 2011, as it will be the last one, AFAIK |
| 2010-11-05 10:44:16 utc | jmettraux | :-) rumours |
| 2010-11-05 10:44:47 utc | skade | hopefully :) |
| 2010-11-05 10:44:49 utc | jmettraux | tosch_le: meet skade, he comes from Germany as well |
| 2010-11-05 10:45:37 utc | tosch_le | hi skade! welcome on #ruote from me, too :-) |
| 2010-11-05 10:46:21 utc | skade | hi torsten :) |
| 2010-11-05 10:50:54 utc | skade | actually, I'm making my first steps with ruote in web application now and i have a few questions :) |
| 2010-11-05 10:51:09 utc | jmettraux | please fire |
| 2010-11-05 10:51:14 utc | skade | first of all: is it better to pass FEIs or WFIDs around? |
| 2010-11-05 10:51:18 utc | tosch_le | great. we're question-hungry here :-) |
| 2010-11-05 10:51:36 utc | jmettraux | the wfid is included in the fei |
| 2010-11-05 10:51:44 utc | jmettraux | the wfid is a "workflow instance id" |
| 2010-11-05 10:51:48 utc | tosch_le | it depends |
| 2010-11-05 10:51:53 utc | jmettraux | it points to a unique process instance |
| 2010-11-05 10:52:18 utc | jmettraux | a fei points to an expression inside of the process instance, or to the workitem emitted by that expression |
| 2010-11-05 10:52:41 utc | jmettraux | so wfid => process instance, fei => point in the process instance |
| 2010-11-05 10:53:10 utc | skade | well, basically, i'm trying to implement something similar to barley |
| 2010-11-05 10:53:42 utc | skade | a complex sequence of questions and then some operations afterwards |
| 2010-11-05 10:55:22 utc | tosch_le | barley uses the wfid iirc |
| 2010-11-05 10:55:47 utc | jmettraux | yes, since it's a loop and has only 1 workitem "out" at any moment |
| 2010-11-05 10:56:21 utc | skade | if so, the parameter naming is wrong :) |
| 2010-11-05 10:56:53 utc | jmettraux | argh |
| 2010-11-05 10:57:41 utc | skade | also, AFAIK, FlowExpressionId.from_id takes the string-form of a fei and turns it into a FEI object |
| 2010-11-05 10:58:13 utc | jmettraux | haven't looked in a while, probably barley is outdated by now |
| 2010-11-05 10:58:30 utc | skade | okay, just checked, it passes the fei |
| 2010-11-05 10:59:06 utc | tosch_le | skade: it really depends on what you want to achieve. when querying the storage participant for instance, the wfid is sufficient |
| 2010-11-05 10:59:54 utc | tosch_le | (but you may get more than one workitem back) |
| 2010-11-05 11:00:10 utc | skade | well, in this case i can ensure that i only have one workitem |
| 2010-11-05 11:02:01 utc | skade | okay, so I'll pass around the wfid |
| 2010-11-05 11:02:16 utc | skade | (looks nicer anyways) |
| 2010-11-05 11:02:42 utc | skade | next question: is there any clean way to avoid the sleep calls in barley? |
| 2010-11-05 11:03:59 utc | jmettraux | let me look at it again |
| 2010-11-05 11:04:52 utc | jmettraux | I'd say, drop them entirely, they're only here to give an appearance of synchronicity |
| 2010-11-05 11:05:30 utc | skade | well, i think they are there to avoid a race |
| 2010-11-05 11:06:06 utc | tosch_le | no, there there to not confuse the user: he expects his changes to appear immediately, but ruote may take longer |
| 2010-11-05 11:06:20 utc | tosch_le | (than the rendering of the index page) |
| 2010-11-05 11:06:23 utc | jmettraux | exactly |
| 2010-11-05 11:07:58 utc | skade | well, that would be the race: the client querys the process before route actually stored the change || process |
| 2010-11-05 11:09:08 utc | tosch_le | ok, but you'll don't get corrupted data that way |
| 2010-11-05 11:09:33 utc | skade | so, is there any reliable way to build a sequence of steps that _one_ user has to fulfill over multiple requests in a web application? |
| 2010-11-05 11:09:33 utc | tosch_le | aaaah s/you'll don't get/you won't get/ |
| 2010-11-05 11:10:17 utc | tosch_le | simple and reliable in 99.9% of all times: sleep a moment before redirecting the user |
| 2010-11-05 11:10:59 utc | skade | :) |
| 2010-11-05 11:11:02 utc | tosch_le | more complex: show the user a waiting screen, query the engine every few cycles and check if the workitem re-appears |
| 2010-11-05 11:11:14 utc | tosch_le | and then redirect the user/show the new form |
| 2010-11-05 11:11:36 utc | skade | okay, i had that solution in mind :) |
| 2010-11-05 11:11:48 utc | skade | but... well... polling :) |
| 2010-11-05 11:12:10 utc | tosch_le | well, there's wait_for, but it's best used in testing only |
| 2010-11-05 11:12:22 utc | skade | i wanted to avoid that |
| 2010-11-05 11:12:47 utc | skade | wouldn't wait_for wait for any workitem delivered to a certain participant? |
| 2010-11-05 11:13:13 utc | tosch_le | yes. one of the two reasons why wait_for should be used in testing only ;-) |
| 2010-11-05 11:13:27 utc | skade | whats the second? :) |
| 2010-11-05 11:13:44 utc | tosch_le | it needs the logger activated afair |
| 2010-11-05 11:14:41 utc | skade | okay |
| 2010-11-05 11:15:10 utc | tosch_le | another solution for you: use you own participant implementation (extend storage participant for instance). that way you may get a message when the workitem arrives |
| 2010-11-05 11:15:21 utc | tosch_le | -> no polling needed |
| 2010-11-05 11:15:45 utc | skade | okay, i also considered that |
| 2010-11-05 11:15:47 utc | skade | last question: storage participants don't thread. Does that mean that i can expect my item to be stored after the reply call? |
| 2010-11-05 11:16:25 utc | jmettraux | it could be possible to write a special participant for webflow, since you want a webflow |
| 2010-11-05 11:16:42 utc | jmettraux | but that would require some rack hacking |
| 2010-11-05 11:17:02 utc | jmettraux | to get into the request/response cycle |
| 2010-11-05 11:17:19 utc | skade | well, that would be interesting |
| 2010-11-05 11:17:35 utc | skade | especially because this little questionnaire is just the beginning :/ |
| 2010-11-05 11:18:06 utc | jmettraux | somehow, is ruote really the right tool for that ? |
| 2010-11-05 11:19:26 utc | jmettraux | I guess, if you have only one worker inside of the web application it could be ok |
| 2010-11-05 11:19:46 utc | jmettraux | when the request comes, you keep a reference to it in the workitem |
| 2010-11-05 11:20:09 utc | skade | well, all users are identifiable, i could keep a reference to the user |
| 2010-11-05 11:20:10 utc | jmettraux | when the engine is done, the request is fetched back and the response is generated |
| 2010-11-05 11:21:04 utc | jmettraux | some people use comet or websockets to circumvent the tight http req/res thing |
| 2010-11-05 11:21:59 utc | jmettraux | sorry, I go in three directions at once |
| 2010-11-05 11:22:48 utc | skade | hehe :) |
| 2010-11-05 11:23:29 utc | skade | okay, maybe i'll explain a bit more context |
| 2010-11-05 11:24:35 utc | skade | meh, finding a generic explanation for you systems internals... |
| 2010-11-05 11:27:40 utc | skade | okay, basically, we're having a small frontend application where people can fill out questionnaires and thats about it |
| 2010-11-05 11:28:26 utc | skade | after that, we have backend users that sort and select those people in multiple stages according to "a process" that is previously undefined |
| 2010-11-05 11:29:28 utc | skade | the backend application is asynchronous, so we really don't mind whether a change is applied in 2ms or 2 seconds |
| 2010-11-05 11:29:55 utc | skade | we considered ruote because we have to sanely model and track "the process" :) |
| 2010-11-05 11:31:48 utc | jmettraux | back |
| 2010-11-05 11:32:23 utc | jmettraux | just afraid that ruote might be a bit "not snappy enough" for the webflow part |
| 2010-11-05 11:33:10 utc | jmettraux | as tosch_le said, maybe you're better off with a custom participant for this webflow |
| 2010-11-05 11:33:40 utc | skade | well, i wouldn't mind building customizations |
| 2010-11-05 11:33:52 utc | skade | at the moment, i'm more interested in the possiblity to do so |
| 2010-11-05 11:33:58 utc | jmettraux | :-) |
| 2010-11-05 11:34:46 utc | skade | actually, in the backend, "the web flow" is also not that important |
| 2010-11-05 11:34:57 utc | jmettraux | understood |
| 2010-11-05 11:35:05 utc | skade | once a person has advanced a stage, he will wait in that stage for 2 days or so |
| 2010-11-05 11:39:36 utc | skade | okay, thanks for all the answers, i'm back to the drawing board |
| 2010-11-05 11:39:50 utc | jmettraux | have fun |
| 2010-11-05 11:41:27 utc | tosch_le | bye! |
| 2010-11-05 11:53:11 utc | jmettraux | tosch_le: in fact, since there is only 1 workitem out for such a webflow, we could use engine.wait_for(wfid), it should be ok |
| 2010-11-05 11:53:42 utc | tosch_le | ok, i'll keep that in mind |