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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users