[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[eclipse-dev] RE: Why should the listener be model-specific
|
Gover,
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
JFace.
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,
Nick