Not sure how you represent the Fields, I guess they are facts. Then what you've suggested is the usual approach, which I'm reducing to
   TabSingle( $field: field )
   Field( this == field,...)

If you have events with multiple fields, you can split this up
when
   TabMultiple( $fields: fields )
   $field: Field( this memberOf fields )
then
   insert( new TabSingle( $field ) );
end

And I'm sure you can guess how the "overall" event should work.

There is an ongoing discussion whether it is better to have many rules, i.e., one for each field with all the parameters coded into it, or only a few, e.g., one per type of checking action with parameters coming from a matched Parameter fact.

-W



On 14 April 2011 23:14, Robert Christenson <rac@akc.org> wrote:
I will concede that we had discussed an AgendaFilter only recently and a prototype did prove successful.

It may not be ideal and based on this thread I'm challenging my team for a pure rule solution.

Our specific issue is that the rules need to activate both when a field is tabbed off in a GUI, but also as a result of a higher-level validation of all data within our larger dog show event.  In this case, if I added specific logic to the rule, how/when could the rule activate when the overall event is submitted to the session?  Perhaps Context( (action == all) || (action == taboff, fieldsAffected contains field1)

I viewed the filter as a direct way to allow the activations to be filtered (in the case of taboff, keep only the rules affected by the field)

I would welcome any suggestions, I'm still trying to learn as much as I can.

Sorry for the smell.

-bob
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users