Where do we go from here?

So far, I've posted two articles on how to get started with the Common Navigator Framework (CNF). There's alot more that can be done though, and I'd like feedback from you about what you're most interested in. Eventually, most if not all, of the pieces of the framework will have an article, but the prioritization should be driven by the community. To that end, I ask the wildly open end question, what do you want to learn about next?

There are several large posting topics that come to mind right off:

• Use cases and motivation for an extensible viewer. The posts so far jumped right into building extensions, but some in the community may not see the reason for having an extensible viewer framework. Is this topic worth an article? Does anyone care about the history or the evolution of the CNF? Or the lessons learned along the way? Or what about what it takes to contribute a component to the Eclipse Platform -- turning a product solution into a Platform-worthy API?
  
  
• Contributing or consuming actions. You can contribute actions or use the API in your own viewers to drive generically extensible menus. You can also structure action extensions that are turned on and off with their content extension, or you can structure menu contributions that have dependencies on other menu contributions (such as contributing to a submenu). The CNF supports object and viewer contributions as well as a CNF-specific programmatic menu builder. You can also contribute to the retargetable actions of the workbench based on the selection in the viewer. Which of these articles would be valuable to you?
  
  
• Filters. I covered some of what you can do with filters in the first posting, was this enough? Do you want to see a programmatic example?
  
  
• Sorting. Sorting in a generic viewer is a nontrivial problem because there does not seem to be an intuitive approach. Therefore, one has to be arbitrarily decided. Even then, some may disagree with the limitations that are imposed. Are any of you interested in providing feedback about what you'd expect? Or do you just want to see an example of contributing sorters to a CNF viewer?
  
  
• Drag and Drop. The CNF supports extensibility for drag transfer data types (specific to the viewer) and extensiblity for drop handling (specific to extensions). You can contribute a DND handler for moving items within a viewer or for moving items from a Common Navigator to another an editor or view in the workbench. Would you like to see how to define your own transfer data type for a viewer? Or what about just adding your own drop handler?
  
  
• Reusing the API outside of the org.eclipse.ui.navigator.CommonNavigator view-part implementation. There are many pieces of the CNF that are designed to be reusable outside of the standard view part implementation. Indeed, Michael Valenta's post is a great example of using the API to construct your own custom extensible viewer class, which doesn't depend on org.eclipse.ui.navigator.CommonNavigator or CommonViewer.
  

Then there are several smaller topics that might be of interest:

• Defining retargetable actions. The CNF allows extensions to define their own default Open action (e.g., what happens when the user double clicks a node you've added?), as well as all of the other retargetable actions defined by the workbench (see org.eclipse.ui.actions.IActionFactory) or your own custom retargetable actions.
  
  
• Setting text in the status bar of the workbench. CNF extensions may use different text to describe their items in the status bar of the workbench than they use to label the item in the viewer.
  
  
• Using custom fonts and color for items. Who says that plain old font is good enough? Get fancy with it.
  
  
• Using mementos to restore or persist state between sessions. CNF extensions may remember state from session to session, providing consistency in the user's experience.
  
  
• Binding an extension programatically to a viewer. You've seen how to bind an extension to a viewer using the org.eclipse.ui.navigator.viewer extension point, but did you know you can drive this directly through the API?
  
  
• Turning extensions on and off programatically. Again, the CNF allows you to programmatically customize a viewer using the API.
  
  
• Defining and Using Wizard Shortcut actions. The CNF allows extensions to declare wizard shortcut actions based on existing org.eclipse.ui.xxxWizards extensions. The text and icon is automatically picked up from the wizard definition, which means the action's text and icon updates when the wizard definition changes. Consumers of the framework can also reuse the API in their own viewers, without any CNF dependencies to render their own context menu with New, Import, and Export wizard shortcut actions with very little code.
  
  
• Hiding the default toolbar buttons and tabs in the filters dialog. Some viewers don't care about link with editor or collapse all, and some viewers don't want to expose the ability to turn filters or extensions on and off to the user. Care to know how?
  
  
• Adding a link with editor handler. An oddly placed addition to the CNF is the link with editor extension point. It's not really core to something like the CNF, but it's something that most viewers (particularly navigational viewers) need. For custom editors or models, clients can add their own link with editor handlers; would this be interesting to you?

I'll end this posting with a couple of diagrams I used at EclipseCon 2006 to convey a high level conceptual model of how the extension points are structured. Feel free to post your own questions about these diagrams or your own topic ideas.

In each diagram, the boxes with the component icon (the not-green-C, not-purple-I icon) are the elements in the extension point. The other boxes (with green Cs and purple-Is) show the classes or interfaces (respectively) defined by the element. The allowed cardinality is denoted between each element and its child.

The first diagram shows the org.eclipse.ui.navigator.navigatorContent extension point.


The second diagram shows the org.eclipse.ui.navigator.viewer extension point.