Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 73143

Summary: Notification Gatherer
Product: [Modeling] EMF Reporter: Constantine Plotnikov <cap>
Component: CoreAssignee: Marcelo Paternostro <marcelop>
Status: RESOLVED WONTFIX QA Contact:
Severity: enhancement    
Priority: P5 CC: Ed.Merks, psodre
Version: 2.1   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
an notification gatherer implementation, samples and test none

Description Constantine Plotnikov CLA 2004-09-02 09:05:59 EDT
I would like to offer the Notification Gatherer component for 
inclusion into EMF project on behalf of IBM Advanced Technology 
Solutions. The component has been already used in two projects 
developed by IBM ATS.

The Notification Gatherer component is a simple utility component 
that automates listening to events that happen in EMF object graph. 
Such code usually is not very complex, but it is quite error prone 
because a lot of small things should be done in a lot of places. So, 
from our experience, the component enhances clarity of the code and 
reduces number of bugs.

The component is a reimplementation of the idea that was previously 
implemented in NSMDF and NSUML open source projects. These projects 
have an idea that is similar to EMF one, but their APIs 
significantly differ from EMF API.

This component allows gathering events for an object and the objects 
reachable from it according to a declaratively defined strategy.

The component is developed to detect changes that might affect some 
value derived from the object state. Such value could be affected 
not only by the values of attributes of the object, but also by the 
values of some attributes of the objects reachable from the object 
by some attribute paths. Notification gatherer is attached to the 
EMF object with respect to which a value should be calculated.

An instance of NotificationGatherer gathers events according to 
strategy that is specified in objects of type 
NotificationGathererStrategy that are passed to it as arguments to 
the constructor. The strategy object is only applicable to objects 
of a type that is passed as an argument to the constructor of 
NotificationGathererStrategy.

The strategy allows specifying two kinds of policies to be specified 
for a gatherer object attached to some object:

* Listen to changes in the value of the specified property of the 
current object of a gatherer.

* Listen to changes in the value of the specified property of the 
current object of a gatherer and to changes in objects reachable via 
the property according to the specified strategy. If this option is 
specified, when an object becomes reachable from the current object 
a child notification gatherer is created that listen to events 
according to the matching strategies and notify parent.

The attached is an archive with three Eclipse projects that could be 
imported into newly created workplace as existing projects:
* temp.emf.ecore.notificationgatherer - a notification gatherer 
implementation.
* temp.emf.ecore.notificationgatherer.samples - a tutorial and code 
for samples used in it.
* temp.emf.ecore.notificationgatherer.tests - a JUnit test case for 
notification gatherer. This test covers many features of the 
NotificationGatherer component but it is still incomplete. The 
previous more complete iteration of the test used application 
specific model. This version of test uses EMF model as foundation 
for test.

The suggested place for the component is "org.eclipse.emf.ecore" 
plug-in. This component has strong dependency on Ecore model and the 
component can be used for implementation of the derived features in 
EMF objects (see tutorial for more information).
Comment 1 Constantine Plotnikov CLA 2004-09-02 09:09:15 EDT
Created attachment 14352 [details]
an notification gatherer implementation, samples and test
Comment 2 Ed Merks CLA 2005-02-18 07:25:04 EST
[plan pri=4 est=2w/]
Comment 3 Ed Merks CLA 2006-10-27 05:30:30 EDT
Constantine,

There hasn't been sufficient interest in this and given our growing list of enhancement requests, it doesn't seem likely that this will be something we can absorb and maintain any time soon. I'll mark it as later for potential future consideration.
Comment 4 Eclipse Webmaster CLA 2009-08-30 02:50:37 EDT
LATER/REMIND bugs are being automatically reopened as P5 because the LATER and REMIND resolutions are deprecated.
Comment 5 Ed Merks CLA 2009-09-02 12:38:27 EDT
Changing to WONTFIX because of the disappearance of the later/remind resolution.