The common navigator is a JFace TreeView
component that has extension points for displaying arbitrary types of objects. Instead of having to write content and label providers for all sorts of different objects, the common navigator provides a tree view that allows plug-ins to contribute different renderers based on the type of object in the tree.
The common navigator is used by the Project Explorer view in Eclipse and is used to show the graphics and labels for the packages, classes, and their methods and fields, as shown in the following screenshot. It is also used in the enterprise Java plug-in to provide Servlet and context-related information.
None of the resources shown in the screenshot of the Project Explorer view exist as individual files on disk. Instead, the Project Explorer view presents a virtual view of the web.xml
contents. The J2EEContentProvider
and J2EELabelProvider
nodes are used to expand the available content set and generate the top-level node, along with references to the underlying source files.
Note
Note that, as of Eclipse 4.4, the common navigator is an Eclipse 3.x plug-in, and as such, works with the Eclipse 3.x compatibility layer. CommonViewer
provides a JFace TreeViewer
subclass that may be suitable in standalone E4 applications. However, it resides in the same plug-in as the CommonNavigator
class that has dependencies on the Eclipse 3.x layer, and therefore may not be used in pure E4 applications.
Creating a content and label provider
The common navigator allows plug-ins to register a JFace ContentProvider
and LabelProvider
instance for components in the tree. These are then used to provide the nodes in the common navigator tree.
Tip
For more information about content providers and label providers, see chapter 3 of Eclipse 4 Plug-in Development by Example Beginner's Guide, Packt Publishing, or other tutorials on the Internet.
To provide a content view of the feed's properties file, create the following classes:
Feed
(a data object that contains a name and URL)
FeedLabelProvider
(implements ILabelProvider
)
FeedContentProvider
(implements ITreeContentProvider
)
The FeedLabelProvider
class needs to show the name of the feed as the label; implement the getText
method as follows:
Optionally, an image can be returned from the getImage
method. One of the default images from the Eclipse platform could be used (for example, IMG_OBJ_FILE
from the workbench's shared images). This is not required in order to implement a label provider.
The FeedContentProvider
class will be used to convert an IResource
object into an array of Feed
objects. Since the IResource
content can be loaded via a URI, it can easily be converted into a Properties
object, as shown in the following code:
The getElements
method is not invoked when ITreeContentProvider
is used; but conventionally, it can be used to provide compatibility with other processes if necessary.
Integrating into Common Navigator
The providers are registered with a navigatorContent
element from the extension point org.eclipse.ui.navigator.navigatorContent
. This defines a unique ID, a name, an icon, and whether it is active by default or not. This can be created using the plug-in editor or by adding the configuration directly to the plugin.xml
file, as shown:
Running the preceding code will cause the following error to be displayed in the error log:
The navigatorContent
extension, needs to be told when this particular instance should be activated. In this case, when an IResource
is selected with an extension of .feeds
, this navigator should be enabled. The configuration is as follows:
Adding the preceding code to the plugin.xml
file fixes the error. There is an additional element, possibleChildren
, which is used to assist in invoking the correct getParent
method of an element:
The purpose of doing this is to tell the common navigator that when a Feed
instance is selected, it can defer to the FeedContentProvider
to determine the parent of a Feed
. In the current implementation, this does not change, since the getParent
method of the FeedContentProvider
returns null
.
Running the Eclipse instance at this point will fail to display any content in the Project Explorer view. To do that, the content navigator extensions need to be bound to the right viewer by its ID.
Binding content navigators to views
To prevent every content navigator extension from being applied to every view, individual bindings allow specific providers to be bound to specific views. This is not stored in the commonNavigator
extension point, as this can be a many-to-many relationship. Instead, a new extension point, org.eclipse.ui.navigator.viewer
, and a nested viewerContentBinding
point are used:
The viewerId
declares the view for which the binding is appropriate.
Tip
A list of viewerId
values can be found from the Host OSGi Console by executing the following command:
This provides a full list of IDs contained within the declarations of the extension point org.eclipse.ui.views
. Note that not all of the IDs may be views, and most of them won't be subtypes of the CommonNavigator
view.
The pattern defined in the content extension can be a specific name (such as the one used in the example previously) or it can be a regular expression, such as com.packtpub.*
, to match all extensions in a given namespace.
Running the application now will show a list of the individual feed elements underneath news.feeds
, as shown in the following screenshot:
Adding commands to the common navigator
Adding a command to the common navigator is the same as other commands; a command
and handler
are required, followed by a menuContribution
that targets the appropriate location URI.
To add a command to show the feed in a web browser, create a ShowFeedInBrowserHandler
class that uses the platform's ability to show a web page. In order to show a web page, get hold of the PlatformUI
browser support, which offers the opportunity to create a browser and open a URL. The code is as follows:
If the selection is an IStructuredSelection
, its elements will be processed; for each selected Feed
, a browser will be opened. The StatusManager
class is used to report an error to the workbench if there is a problem.
The command will need to be registered in the plugin.xml
file as follows:
To use this in a pop-up menu, it can be added as a menuContribution
(which is also done in the plugin.xml
file). To ensure that the menu is only shown if the element selected is a Feed
instance, the standard pattern for iterating over the current selection is used, as illustrated in the following code snippet:
Tip
For more information about handlers and selections, see chapter 3 of Eclipse 4 Plug-in Development by Example Beginner's Guide, Packt Publishing, or other tutorials on the Internet.
Now, when the application is run, the Show Feed in Browser menu will be shown when the feed is selected in the common navigator, as illustrated in the following screenshot:
If the file changes, then currently the viewer does not refresh. This is problematic because additions or removals to the news.feeds
file do not result in changes in the UI.
To solve this problem, ensure that the content provider implements IResourceChangeListener
(as shown in the following code snippet), and that when initialized, it is registered with the workspace. Any resource changes will then be delivered, which can be used to update the viewer.
Now when changes occur on the underling resource, the viewer will be automatically updated.
Optimizing the viewer updates
Updating the viewer whenever any resource changes is not very efficient. In addition, if a resource change is invoked outside of the UI thread, then the refresh operation will cause an Invalid Thread Access error message to be generated.
To fix this, the following two steps need to be performed:
To run the refresh
method inside a UIJob
class, replace the call with the following code:
This will ensure the operation works correctly, regardless of how the resource change occurs.
To ensure that the viewer is only refreshed on resources that really need it, IResourceDeltaVisitor
is required. This has a visit
method which includes an IResourceDelta
object that includes the changed resources.
An inner class, FeedsRefresher
, that implements IResourceDeltaVisitor
can be used to walk the change for files matching a .feeds
extension. This ensures that the display is only updated/refreshed when a corresponding .feeds
file is updated, instead of every file. By returning true
from the visit
method, the delta
is recursively walked so that files at any level can be found. The code is as follows:
This is hooked into the feed content provider by replacing the resourceChanged
method with the following code:
Although the generic viewer only has a refresh
method to refresh the entire view, StructuredViewer
has a refresh
method that takes a specific object to refresh. This allows the visit to be optimized further, as shown in the following code snippet:
Linking selection changes
There is an option in Eclipse-based views: Link editor with selection. This allows a view to drive the selection in an editor, such as the Outline view's ability to select the appropriate method in a Java source file.
This can be added into the common navigator using a linkHelper
. To add this, open the plugin.xml
file and add the following to link the editor whenever a Feed
instance is selected:
This will set up a call to the FeedLinkHelper
class that will be notified whenever the selected editor is a plain file or the object is of type Feed
.
To ensure that linkHelper
is configured for the navigator, it is necessary to add it in to the includes
element of the viewerContentBinding
point created previously, as shown in the following code:
FeedLinkHelper
needs to implement the interface org.eclipse.ui.navigator.ILinkHelper
, which defines the two methods findSelection
and activateEditor
to convert an editor to a selection and vice versa.
To open an editor and set the selection correctly, it will be necessary to include two more bundles to the project: org.eclipse.jface.text
(for the TextSelection
class) and org.eclipse.ui.ide
(for the IDE
class). This will tie the bundle into explicit availability of the IDE, but it can be marked as optional (because if there is no IDE, then there are no editors). It may also require org.eclipse.ui.navigator
to be added to include referenced class files.
To implement the activateEditor
method, it is necessary to find where the entry is inside the properties file and then set the selection appropriately. Since there is no easy way to do this, the contents of the file will be read instead (with a BufferedInputStream
instance) while searching for the bytes that make up the selected item. Because there is a hardcoded name of bookmarks
and a feed of news.feeds
, this can be used to acquire the file content; though for real applications, the Feed
object should know its parent and be able to provide that dynamically. The following code snippet shows how to set the selection appropriately:
To find the content of the line, it is necessary to get the contents of the file and then perform a pass-through looking for the sequence of bytes. If the bytes are found, the start point is recorded and is used to return a TextSelection
. If they are not found, then return a null
, which indicates that the value shouldn't be set. This is illustrated in the following code snippet:
This takes advantage of the fact that BufferedInputStream
will perform the mark
operation on the underlying content stream and allow backtracking to occur. Because this is only triggered when the first character of the input is seen, it is not too inefficient. To further optimize it, the content could be checked for the start of a new line.
Once the appropriate selection has been identified, it can be opened in an editor through the IDE
class. This provides an openEditor
method that can be used to open an editor at a particular point, from which the selection service can be used to set the text selection on the file. The code is as follows:
Now when the element is selected in the project navigator, the corresponding news.feeds
resource will be opened as long as Link editor with selection is enabled.
The corresponding direction, linking the editor with the selection in the viewer, is much less practical. The problem is that the generic text editor won't fire the method until the document is opened, and then there are limited ways in which the cursor position can be detected from the document. More complex editors, such as the Java editor, provide a means to model the document and understand where the cursor is in relation to the methods and fields. This information is used to update the outline and other views.