Issue 10736: FilterCriterion (data-distribution-rtf)
Source: PrismTech (Mr. Erik Hendriks, erik.hendriks(at)prismtech.com)
Nature: Revision
Severity: 
Summary: Problem:

When a Selection is in auto_refresh mode, normal operation is that it only evaluates objects in the update round in which they receive updates: objects that do not get updated have no reason to enter/exit a Selection. However, that mechanism is based on the assumption that the filter only evaluates the state of the object itself. What if the filter evaluates other things, like the state of related objects. Then the filter should also be re-applied if the state of such a related object changes.

Solution:

There may be a need to set the scope of a FilterCriterion: this scope will then define when and how objects should be re-evaluated by the Selection.

TBD. 

Resolution: 
Revised Text: 
Actions taken:
February 14, 2007: received issue
Discussion: 
The FilterCriterion should have some mechanism to define the scope and granularity of updates it needs to process when in auto_refresh mode
End of Annotations:=====
s is issue # 10736	From: "Erik Hendriks" <Erik.Hendriks@prismtech.com>


FilterCriterion
The FilterCriterion should have some mechanism to define the scope and granularity of updates it needs to process when in auto_refresh mode

Problem:

When a Selection is in auto_refresh mode, normal operation is that it only evaluates objects in the update round in which they receive updates: objects that do not get updated have no reason to enter/exit a Selection. However, that mechanism is based on the assumption that the filter only evaluates the state of the object itself. What if the filter evaluates other things, like the state of related objects. Then the filter should also be re-applied if the state of such a related object changes.

Solution:

There may be a need to set the scope of a FilterCriterion: this scope will then define when and how objects should be re-evaluated by the Selection.

TBD.