It helps a lot, thank you. I don't actually find the decision participant more readable in simple cases because the business rule is buried in the participant implementation. I like the idea of decision tables for more complex cases though. However, the ruby eval syntax you provided will get me going for now. Is there a decent expression evaluator library around for ruby? I have only run across one so far, but it is GPL licensed. I come from .net and they are everywhere because there is no possibility of a language level "eval." But sometimes for expressing human readable business rules a simple sandboxed expression language really fits the bill. Maybe it is finally time to take Treetop for a spin.
Thanks again for the help. On Aug 30, 2010, at 10:04 PM, "John Mettraux" <[email protected]> wrote: > > On Mon, Aug 30, 2010 at 08:55:15PM -0700, Nathan Stults wrote: >> >> I am thoroughly enjoying your framework. I really like the way it is >> designed, easy to use, easy to extend. Anyway, I have a quick question >> regarding conditions. > > Hello, > > many thanks ! > >> What is the recommended approach to and'ing and >> or'ing expressions, like this (which doesn't seem to work) >> >> _if :test=>'${f:consent_form_on_file} == yes && ${f:is_patient_eligible} >> == yes' do >> >> Looking at the implementation of Condition I can see why what I'm trying >> to do isn't working, but I was wondering if there is some way? Is there >> a way to provide an array of conditions and an operator, or should I try >> to use nesting of flow expressions or something? I'm happy to use Ruby >> eval as well, but in that case I'm not sure how to get hold of work item >> variables. Can dollar syntax be used with ruby eval in expressions? > > OK, I will answer in variants : > > == decision participants > > I tend to use "decision participants" like in > > ---8<--- > sequence do > decide > _if "${f:decided}" do > accept > reject > end > end > --->8--- > > Where the 'decision participant' might look like > > ---8<--- > class DecisionOne > include Ruote::LocalParticipant > > def consume(workitem) > > workitem.fields['decided'] = > workitem.fields['is_patient_eligible'] && > workitem.fields['consent_form_on_file'] == 'yes' > > reply_to_engine(workitem) > end > end > > # ... > > engine.register_participant 'decide', DecisionOne > --->8--- > > This makes the process definition more readable and lets you change the > decision logic independently from the business process. > > That implies being able to hook more complex decisions (rule engine, decision > tables, your own complex decision library) or simply, sometimes, when the > decision is very very complex, switch from an automated participant to a > human participant (our dear friend the "knowledge worker"). > > > == ruby evaluation > > You can write : > > ---8<--- > _if "${r:wi.fields[consent_form_on_file] == 'yes' && > wi.fields['is_patient_eligible']}" > --->8--- > > Within the ${r: } you're free to use ruby code (and to shoot yourself in the > foot with it). There is a minimal sanity check ( > http://github.com/jmettraux/ruote/blob/ruote2.1/lib/ruote/util/treechecker.rb > ) but you have to have ruby evaluation allowed : > > ---8<--- > engine.context['ruby_eval_allowed'] = true > --->8--- > > > == hypothetical variant > > Not a real variant : I have thought of things like > > ---8<--- > sequence do > decide > _if do > _and do > test "${f:consent_form_on_file} == yes" > test "${f:is_patient_eligible}" > end > accept > reject > end > end > --->8--- > > but I never implemented it, preferring to guide people towards decision > participants or the ${r: } notation. > > > I hope this will help, best regards, > > -- > 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
