ruote log_2010-11-05

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