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 <[email protected]> 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users >
_______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
