Using the Common Navigator Framework in an RCP Application
April 20th, 2007 | Published in Rich Client Platform | 14 Comments
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.
Patrick on the RCP Panel at EclipseCon
April 20th, 2007 at 7:52 pm (#)
Very nice. Good to know. There are several cases, where I could have used the framework, but didn’t want to do the work ;-)
Thanks,
Tonny
April 21st, 2007 at 6:17 am (#)
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 :)
April 25th, 2007 at 9:35 pm (#)
[...] org.eclipse.ui.navigator.CommonNavigator class in this field. To learn why we are not, check out my previous post on the [...]
June 21st, 2007 at 7:50 pm (#)
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.
June 21st, 2007 at 10:11 pm (#)
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.
October 31st, 2007 at 1:54 pm (#)
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?
November 1st, 2007 at 3:04 pm (#)
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.
Regards,
— Patrick
November 5th, 2007 at 5:01 pm (#)
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.
November 7th, 2007 at 5:15 pm (#)
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?
November 7th, 2007 at 9:14 pm (#)
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
November 8th, 2007 at 3:11 pm (#)
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 (NavigatorContentDescriptor.java 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:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=209194
November 8th, 2007 at 6:56 pm (#)
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.
April 16th, 2008 at 12:03 am (#)
Thanx a lot !!!
You saved my day
October 6th, 2009 at 7:37 am (#)
[...] all the posts I’ve written on this blog, those on the Common Navigator Framework have been among the most popular. This is a little surprising to [...]