[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse-dev] RE: Why should the listener be model-specific


We don't define a single listener interface for models because every model 
is different, and we didn't want to require models to have a dependency on 
We designed the viewer framework so that we impose no requirements on the 
model, other than that it have some way of hooking notification about 
changes to it.

This also lets the content provider optimize viewer update for the 
particular model, which is next to impossible to do with a generic 
listener approach.

For example, the Workspace in Core knows nothing about JFace or Eclipse 
UI.  It has a batch oriented delta mechanism which tells listeners about 
changes to the whole tree since the last notification, not just piecemeal 
changes to single resources at a time.  The content provider for the 
Navigator hooks into this mechanism, recurses over the delta, and sends a 
maximum of 3 requests to the viewer (all the additions, all the removals, 
and all the changes to existing elements).  See 
org.eclipse.ui.model.WorkbenchContentProvider for more details.

Now, we could perhaps make things easier for simple models by adding a 
generic listener which models could reuse.
In earlier incarnations of JFace, we actually did have a very generic 
model called IElement, but we actually evolved away from it for the 
reasons above.
(The old approach had a really horrible mapping for the Workspace, trying 
to reverse engineer the delta info from the IElement notifications.)
Since then, we felt it would be a clearer separation of responsibilities 
if we did not provide a generic model or listener.

Hope this clarifies,