Build a view based on the general Navigator architecture (CNF) Part 2: add content

From: http://blog.csdn.net/windy444/archive/2007/12/31/2006304.aspx

Translated by windy444.

Original article name: Building a common navigator framework (CNF) viewer Part II: adding content, Author: Michael elder, source:Http://scribbledideas.blogspot.com/(I have never been able to open it ).

Copyright first

The opinions and ideas expressed tables are my own and do not represent the intent, opinion, or official statement of any company or organization.
All postings by me to this site are copyrighted (c) by Michael D. elder, 2006 and made available under the terms of the eclipse Public License 1.0 with the constraint that any reuse of the content must contain this copyright statement.

In this article, we will learn how to add a simple content extension for the examples defined in the previous article. To avoid getting stuck in overly complex content and tag providers, we will focus on a simple file structure model, simple text file *. properties. When this is done, our content extension will allow you to expand any *. properties file in example viewer and arrange the data correctly below.

First, let's take a look at what content extensions look like in plugin. xml. (Note: Some basic operations are skipped. plugin. XML is as follows :)

The extension uses ID "org. Eclipse. UI. Examples. Navigator. propertiescontent" to define a content extension. The displayed name is "properties file contents ". This name appears in the "available extensions" tab of the filter dialog box. We will immediately take a look at the Java code of the content and tag provider, but now we only need to note that both are specified. You cannot specify only one of them.

Finally, we set some attributes to tell the framework how to expand them:

•ActivebydefaultDetermines whether the extension is activated in the default configuration (for example, new workspace)

•IconDetermines the icon to display when the extension is referenced on the user interface.

•PriorityThere are several different usage methods. The main function is to specify the relative position of the items in the view (the top-down list in the view is the highest priority (highest priority) item to the lowest priority (lowest priority) item ). Generally, "General" ("normal") or "advanced" ("high") is sufficient for most extensions, the two indicate that they are mixed with resource expansion (in alphabetical order if their priorities are the same) or placed on resources under the project.

Within each <navigatorcontent/> element, we can specify extensions of different categories. But before extending our example, we must define to the architecture when our extension will be called. We must define when the Tree nodes in the view can provide children, parents, or labels and icons. We use the eclipse core expression to do this.

There are two important expressions for content Extension: <Triggerpoints/> And <Possiblechildren/>.

<Triggerpoints/> Expression specifies the type of nodes in the tree that are interested in our expansion. When the architecture finds a node that matches <triggerpoints/>, our extension is called to provide child elements for the node. Our extension is not necessarily the only opportunity to provide child element extensions for the node. The architecture will aggregate all the child elements under the node (Note: It can be provided by different extensions ).

<Possiblechildren/> the expression specifies the type of nodes in the tree that our extension can provide tags or parent nodes (Note: different from triggerpoints ). If your scenario must support link with editor or setselection () in the view, the <possiblechildren/> expression must be complete and correct.

Once we define an extension, we must bind it to the view to be associated. Set a <viewercontentbinding/> to specify any extensions that match the include mode. These extensions are visible to any viewerid view specified in the <viewercontentbinding/> element. Refer to the previous article.

Now that we have set the extension, let's take a look at the code that actually handles the transaction.

First, we need a model. The structure of an attribute file is quite simple. We only need to use a model object propertiestreedata to create a model. This object has three fields: Name (attribute name), value (attribute value), and container (file with Attribute Model ). Each model element indicates an attribute in the attribute file.

In our example, the model is loaded only when it is requested by the content provider. The content provider is used by the framework to determine the child elements of each element in the tree, or to specify the parent elements of a given element (there may be multiple ).

The content provider in our example implements the org. Eclipse. jface. Viewers. itreecontentprovider interface to provide information about the tree structure. The general Navigator architecture also supports implementing the content provider of the org. Eclipse. jface. Viewers. itreepathcontentprovider interface, but this is beyond the scope of this example.

Propertiescontentprovider also provides other features required for our extension, such as listening for resource changes and updating models (and views ). It is not covered in this article. You can go to the source code of this article to learn how this works.

Now, we will focus on the view integration method provided by itreecontentprovider.

Itreecontentprovider must be implementedGetelements (Object input), getchildren (Object parent), haschildren (object element)AndGetparent (object element)Method.

The getelements () method is used to query the elements in the view root directory. Many implementations will directly call getchildren () for processing, as we do here.

The getchildren () method accepts an object (here is the ifile ending with *. properties, or the propertiestreedata model instance that must be introduced because it is described in <triggerpoints/> ).

In the following implementation, we check whether the accepted object is org. Eclipse. Core. Resources. ifile and whether it ends with *. properties. If the accepted objects meet these requirements, we check the cache of the load model and try to load the model when it is not cached. The updatemodel () method creates a propertiestreedata object for each attribute and caches the model found in cachedmodelmap. Please check in the source code how the updatemodel () method is implemented.

The haschildren () method is optimized. If you know that the passed object is an ifile ended with *. properties, true is returned. Another replacement method is to load files and perform some calculations here, but this will damage the performance.

If the input object is a propertiestreedata model element, false is returned. Because our model element has no child element. (Attributes do not have child elements, but other models may have them ).

The getparent () method returns the ifile containing the propertiestreedata item. If other parameters are input, null is returned. The general Navigator architecture will continue to ask for other extensions until a non-null parent element is found or all extensions have been traversed. Recall that if the element matches the <possiblechildren/> expression, the extension is required to provide the parent node for the element.

Finally, the tag provider of our content extension will tell the view how to present tags and icons for our model elements (propertiestreedata. Since we only focus on these elements, we don't have to worry about how to provide labels and icons for other elements. These elements will be expanded by others to display labels and icons.

Propertieslabelprovider implements org. Eclipse. jface. Viewers. ilabelprovider and
Org. Eclipse. UI. Navigator. idescriptionprovider interface.

Ilabelprovider is the default Interface requirement for labels and icons in jface.

Idescriptionprovider is specific to the general Navigator architecture and is used to display text in the status bar in the lower left corner of the eclipse window.

The methods required by ilabelprovider are gettext () and getimage (). We will show the model tag a string of "name = value. For icons, we use a sharing icon provided by the platform.

In the following two cases, the tag provider is accessed: 1. Its own extended definition elements. 2. All elements matching <possiblechildren/>. If the icon or label returns NULL, the Framework continues searching for other extensions (to display labels and icons) based on <possiblechildren/> and the view bindings ). If you want others to define tags and icons for your extension, null is returned.

In this case, the final view example view lists the attributes under the attribute file.