Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "FAQ What are content and label providers?"
m |
|||
| Line 1: | Line 1: | ||
| − | Minimally, all content viewers require you to supply | + | Minimally, all content viewers require you to supply a content provider and the label provider to interact with your model. The content provider is the viewer’s gateway to the structure of the model elements that will be displayed in the viewer. When an input is provided to a viewer, the viewer asks the content provider what elements to show for that input. For more complex structures, such as trees, the viewer asks the content provider when it needs to know the children or parent of a given model element. |
| − | a content provider and the label provider to interact with your model. | + | |
| − | The content provider is the viewer’s gateway to the structure of the model | + | |
| − | elements that will be displayed in the viewer. When an input is provided | + | |
| − | to a viewer, the viewer asks the content provider what elements to show | + | |
| − | for that input. For more complex structures, such as trees, the viewer | + | |
| − | asks the content provider when it needs to know the children or parent | + | |
| − | of a given model element. | + | |
| + | In addition to answering these questions from the viewer, the content provider must also notify the viewer whenever the model has been changed. The content provider does this by calling the various incremental update methods on the viewer subclasses. Although these methods look slightly different, depending on the kind of viewer, they generally follow a naming convention: | ||
| − | + | * <tt>add</tt>, for adding a single new element or batches of new elements. | |
| − | + | * <tt>remove</tt>, for removing single elements or batches of elements. | |
| − | + | * <tt>update</tt>, for updating the appearance of a single item, such as the label or icon. Optionally, this method takes a list of properties that are passed to the label provider, filters, and sorters to determine whether they are affected by the change. | |
| − | + | * <tt>refresh</tt> for naive updating of an element and its children. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | * <tt>add</tt>, for adding a single new element or batches of new elements. | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | * <tt>remove</tt>, for removing single elements or batches of elements. | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | * <tt>update</tt>, for updating the appearance of a single item, such as | + | |
| − | the label or icon. Optionally, this method takes a list of properties | + | |
| − | that are passed to the label provider, filters, and sorters to determine | + | |
| − | whether they are affected by the change. | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | * <tt>refresh</tt> for naive updating of an element and its children. | + | |
| − | Although <tt>refresh</tt> is the easiest of these methods to use, it is | + | Although <tt>refresh</tt> is the easiest of these methods to use, it is also generally the least efficient. Because it is provided with no context information to figure out exactly what has changed, it simply rebuilds the view from scratch, starting with the provided element. This can in turn trigger costly sorting and filtering of the elements. |
| − | also generally the least efficient. Because it is provided with no context | + | |
| − | information to figure out exactly what has changed, it simply rebuilds | + | |
| − | the view from scratch, starting with the provided element. This can in | + | |
| − | turn trigger costly sorting and filtering of the elements. | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | The label provider deals only with presentation of individual model elements. The viewer asks the label provider only what text and what icon, if any, are associated with each model element? The label provider is also responsible for disposing of any images it creates when the viewer is disposed of. | ||
== See Also: == | == See Also: == | ||
| + | *[[FAQ What is a viewer?]] | ||
| + | *[[FAQ Why should I use a viewer?]] | ||
| + | *[[FAQ How do I use properties to optimize a viewer?]] | ||
| − | + | {{Template:FAQ_Tagline}} | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Latest revision as of 21:39, 29 May 2006
Minimally, all content viewers require you to supply a content provider and the label provider to interact with your model. The content provider is the viewer’s gateway to the structure of the model elements that will be displayed in the viewer. When an input is provided to a viewer, the viewer asks the content provider what elements to show for that input. For more complex structures, such as trees, the viewer asks the content provider when it needs to know the children or parent of a given model element.
In addition to answering these questions from the viewer, the content provider must also notify the viewer whenever the model has been changed. The content provider does this by calling the various incremental update methods on the viewer subclasses. Although these methods look slightly different, depending on the kind of viewer, they generally follow a naming convention:
- add, for adding a single new element or batches of new elements.
- remove, for removing single elements or batches of elements.
- update, for updating the appearance of a single item, such as the label or icon. Optionally, this method takes a list of properties that are passed to the label provider, filters, and sorters to determine whether they are affected by the change.
- refresh for naive updating of an element and its children.
Although refresh is the easiest of these methods to use, it is also generally the least efficient. Because it is provided with no context information to figure out exactly what has changed, it simply rebuilds the view from scratch, starting with the provided element. This can in turn trigger costly sorting and filtering of the elements.
The label provider deals only with presentation of individual model elements. The viewer asks the label provider only what text and what icon, if any, are associated with each model element? The label provider is also responsible for disposing of any images it creates when the viewer is disposed of.
See Also:
- FAQ What is a viewer?
- FAQ Why should I use a viewer?
- FAQ How do I use properties to optimize a viewer?
This FAQ was originally published in Official Eclipse 3.0 FAQs. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the Eclipse Public License v1.0.