Using the Common Navigator Framework in an RCP Application

The Common Navigator Framework was introduced in Eclipse 3.2 to provide navigators with pluggable content, filters, sorting and much else. It’s a powerful new feature, but for some reason it wasn’t made to work with the RCP. In my opinion. every significant addition to the Eclipse API should be made RCP compatible unless it’s really IDE specific. RCP compatibility shouldn’t just be an afterthought, it should be a core design principle. Ok, I’ll get off my soapbox now.

RCP developers have gone through a lot of pain trying to get the CNF to work, and most of these attempts involve trying to fake out the mechanism that discovers a navigator’s root node. The approach I’ve taken is a bit simpler – just extend it. The core of the CNF is the CommonNavigator class, which is meant to be used as is. My approach is to extend this class and override the getInitialInput method, which is responsible for root node discovery. I’ve done this on a number of projects, and the rest of the CNF works as expected.

Hopefully someday I’ll be able to use the CNF as intended, but this is a small price to pay for now.


13 Responses to Using the Common Navigator Framework in an RCP Application

  1. Tonny Madsen says:

    Very nice. Good to know. There are several cases, where I could have used the framework, but didn’t want to do the work 😉


  2. Kiril Mitov says:

    It was an year ago when I first tried this, but overriding the getInitialInput() method was not a decision a could live with.
    I am glad to here that there are others that have manage to solve this problem and hopefully one day this issue will be solved 🙂

  3. […] org.eclipse.ui.navigator.CommonNavigator class in this field. To learn why we are not, check out my previous post on the […]

  4. Peter Rice says:

    I tried this on 3.3 and it failed. The result is the same old blank view (with all the menus, etc. intact.) I also found out that the NewFileCreationWizard uses the CommonNavigator for its navigator panel, and hence does not work in RCPs.

  5. pjpaulin says:

    Hi Peter,
    This should be working for you in Eclipse 3.3. Maybe the best place to start would be to download the Eclipse 3.3 sample code in the Common Navigator Tutorial post. If the sample runs in your environment, then you can compare the code to yours or use it as a starting point to build your own navigator.
    As for the NewFileCreatonWizard class, I confess I’ve never worked with it before. It looks like a CDT class. I’m not sure what it would take to reuse it in an RCP app, but if you’d like to email me the details, I’d be happy to help.

  6. Raajesh Kashyap says:

    I posted this in the Eclipse platform newsgroup, but have not received a response so far… so I thought I would ask you here.

    We have an RCP app where we are looking to have a central navigator tree which would be able to show different kinds of objects. For example, it may be able to show a set of domain objects from the DB, and then also show a set of recent searches performed, and maybe some other set of objects too. All of these must be top-level roots inside the common navigator. I am wondering if this is possible to do (multiple roots), and how each top-level node must be seeded. Obviously, each of those nodes would have their own content and label providers. However, we are looking for a way to allow customers/users to add their own top-level node (along with their content and label providers). Do you know if that is possible with the CNF, and how to do it?

  7. pjpaulin says:

    Hi Raajesh,

    Well there is always a single root node type for a navigator, and that root never appears directly. From that root, you can add top level (root) nodes in various ways.

    First, you can attach them by using the “triggerPoint” element in the CNF declarations. Search the Eclipse help for more info. Second, you can return elements directly from the content provider of the single root node.

    As for allowing customers/users to add top-level nodes, I’m wondering what type of users they are. I imagine that they must be technical users if they’re specifying their own content and label providers. Are they adding a plug-in to your base product? In that situation, I would just have them add the navigator content via a triggerPoint element that triggers on your single root node type.

    If this isn’t the scenario, then I’d need to know more about what you’re trying to achieve and the mechanisms that the customers/users would have access to. Feel free to email me directly if you’d like to talk about this offline.


    — Patrick

  8. Raajesh Kashyap says:

    Thank you very much. I was able to supply the root objects from the content provider of the single root, and then have content extensions for each of those root objects that were added with triggerPoints that triggered using the “instanceof” condition (since my root objects were of different object types).

    Our customers basically would contribute by adding plug-ins (they would have their IT department do this) to customize the product for their needs. I think we may be able to use these extensions along with an extension that allows them to specify which root nodes they want to add.

  9. Raajesh Kashyap says:

    It does not seem like the CNF provides a way to configure multiple columns to appear – like a TreeTable. Is there a way to do this?

  10. pjpaulin says:

    Hi Raajesh,

    I just looked into the source code for the CommonNavigator class, and it uses a class called CommonViewer with extends TreeViewer. As far as I can tell, this means that CNF doesn’t support a TableTreeViewer.

    If you figure out a way to do it, please let me know.

    — Patrick

  11. Raajesh Kashyap says:

    Hi Patrick,

    I was trying this yesterday. In general, the TreeViewer now supports an ITableLabelProvider as the label provider, so it is possible to add and show TreeColumns inside a TreeViewer (the TableTreeViewer has been deprecated, as seen in the 3.3 documentation).

    However, when I try to provide an ITableLabelProvider for the CommonViewer (which extends TreeViewer), it causes a ClassCastException, because somewhere in the CNF code, it expects an ILabelProvider to be the label provider ( is where the exception comes from). This means that the CNF code needs to be changed to allow this to happen correctly.

    I filed a bug report for this at:

  12. pjpaulin says:

    Well that’s good news I suppose. It’s better that there is some bug than that the CNF has a structural issue with table columns. Thanks for the update.

  13. Mihailo says:

    Thanx a lot !!!
    You saved my day

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: