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

In a typical model-view-controller application, each model typically has one
or more views that listen to it for changes. Normally, each view listens to
a single model and when the model tells it something has changed (via some
change event), the view asks the model for new info.

Note my use of the word "typically" as well as the use of the word "typical"
in the javadoc you quote. There's no restriction here; you can do whatever
you want when you hear that the input has changed.

In this type of usage, you typically (there we go again) have a content
provider that's providing information for the view (which uses a label
provider to display it). The content provider typically acts as a way for
the viewer to interpret the input data.

Whenever the viewer has a new input set, it sends a notification to the
content provider. That's the call to inputChanged().
At this point, the content viewer knows that the input has changed. The
javadoc you quote states:

> A typical use for this method is registering the content provider as a
> listener to changes on the new input (using model-specific means),

What they mean here is that content viewers *may* want/need to talk with the
new input and see what makes it tick. They might want to add listeners to
the input (so they'll know when properties in it change, or when the input
fires some other kind of event.

By "model-specific", they're talking about methods in the input object.

A simple example:
* Suppose we have a viewer that will display the wordcount of a document
* The viewer needs to know when two things happen:
  + The document changes (that's the inputChanged())
  + The *contents* of the current document changes

The first notification is already taken care of. inputChanged() will be
called to tell you there's a new input (document). The content provider just
looks at the new document, counts the words. As part of the input change,
the viewer will ask the content provider for its info and use the label
provider to display the data on the viewer.

The second notification is a bit trickier. As part of the inputChanged()
method you define in your content provider, you'd add a listener to the
document to determine when it changes. Note that the viewer has no idea when
the document content changes; it only knows when the input is set to a
different document.

The content provider's listener will be notified when the document changes.
You can do whatever you want in there, but typically you would notify the
viewer that something changed by calling one of its methods. The viewer will
then ask the content provider for the changed data and use the label
provider to display it.

For some general info on model view controller, visit
http://javadude.com/articles and look at my "MVC in VisualAge" article. (The
first section of the article is a description of MVC that's not specific to
VAJ or anything else.)

Hope this helps!
-- Scott

> -----Original Message-----
> From: eclipse-dev-admin@xxxxxxxxxxx
> [mailto:eclipse-dev-admin@xxxxxxxxxxx]On Behalf Of Govindarajan S
> Sent: Friday, November 23, 2001 6:41 AM
> To: eclipse-dev@xxxxxxxxxxx
> Subject: [eclipse-dev] Why should the listener be model-specific
>
>
> Hi,
>
> Iam just starting to work with Eclipse. My first attempt was the
> Readme view
> example and the Wordview article example.
>
> One thing which struck me while reading the article is, why should the
> listener which is being registered in the IContentProvider be
> model-specific?
>
> To explain it further, in 'createPartControl()' method in objects of type
> ViewPart when we set the input on the viewer using the method
> 'viewer.setInput()' the viewer calls the 'inputChanged(..)' method on the
> ContentProvider.
>
> The doc for the method 'inputChanged()' on the ContentProvider
> states that,
>
> Notifies this content provider that the given viewer's input has been
> switched to a different element.
> A typical use for this method is registering the content provider as a
> listener to changes on the new input (using model-specific means), and
> deregistering the viewer from the old input. In response to these change
> notifications, the content provider propagates the changes to the viewer.
>
> If i have got it right the listener is a model-specific listener. In the
> WordView article example theres a custom listner declared inside the class
> WordFile.
>
> And in the WordContentProvider's 'inputChanged()' method the
> WordContentProvider is registered as a listner.  (WordContentProvider
> implements the model-specific listner)
>
> My question is why should the listener interface be
> model-specific, why cant
> it be a specific fixed interface if its job is to just add and remove
> elements?
>
> hope iam clear
>
> gover
>
>
> _______________________________________________
> eclipse-dev mailing list
> eclipse-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/eclipse-dev
>