I guess the question is how would that string be treated by ruote attribute conditions like :if and :until - as long as they don't do what ruby does and treat all non-nil values as effectively true, I think that approach would work pretty well. Personally, I think raising an error in this case would make the most sense, since the process definition should probably considered non-operational or corruptible if it contains conditions important to the functioning of the process definition that can't be evaluated - but as long as they accept ruby expressions that can't be evaluated as either true OR false (as opposed to an error) then mistakes may be hard to detect.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of John Mettraux Sent: Sunday, October 10, 2010 12:33 AM To: [email protected] Subject: Re: [ruote:2690] Testing workflows On Sat, Oct 09, 2010 at 05:16:39PM +0900, John Mettraux wrote: > > On Sat, Oct 09, 2010 at 12:43:34AM -0700, Nathan Stults wrote: > > > > We almost gave up before we realized we forgot to set ruby eval on > > in the test fixture - maybe ruote should throw if you do ruby > > expressions with that flag not set :) > > excellent point, thanks for the suggestion, I have to do something about it. Nathan, what about, with ruby_eval_allowed = false (default) "result : ${r:1 + 2}" --> "result : ${r:1 + 2}" with ruby_eval_allowed = true "result : ${r:1 + 2}" --> "result : 3" ? -- John Mettraux - http://jmettraux.wordpress.com -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
