You're probably right that Ruby alone will do the job just fine,
particularly with some metaprogramming, as you say. That being the case,
do you have any thoughts on a clean way to inject some context into
ruote's expression evaluation process? It seems to be the one part of
ruote that isn't designed specifically for extensibility. What I'd like
to do is have some influence over the class that is in scope when ruby
functions are evaluated, so that I can handle method missing and write
expressions (similar to your little expression language) like this:

_if "${r:consent_form_on_file == yes and is_patient_eligible}

Instead of 

_if "${r:wi.fields['consent_form_on_file'] == 'yes' &&
wi.fields['is_patient_eligible'] }" do

With liberal use of method missing I can try to resolve unknown symbols
from fields, variables or domain specific constants, and turn the rest
into simple strings. I may very well be able to monkey patch this in,
which is fine, but I wonder if there is any value in having expression
evaluation in general be an official extensibility point, like parsing
and storage and things, or of there is already a natural way of
accomplishing this that I'm not seeing.

Thanks,

Nathan 

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of John Mettraux
Sent: Monday, August 30, 2010 11:10 PM
To: [email protected]
Subject: Re: [ruote:2582] Boolean operators and filters/conditions in
Ruote


On Mon, Aug 30, 2010 at 10:58:47PM -0700, Nathan Stults wrote:
>
> 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.

Sorry, begin curious, which expression evaluator is this ?

> 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.

I tend to use ruby directly to express business rules, with a bit of
eval/metaprogramming/dslery sometimes.


Cheers,

--
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

Reply via email to