eclipse - common navigator framework (CNF)

CNF is part of the eclipse API that provides a general navigation framework (a tree object) with content that can be provided through eclipse plugin.xml extensions. The hard part though is understanding how to get certain types of content to be linked (bound) to specific content and label providers. For simple hierarchies, this is not a big deal, but for complex hierarchies where the content is spread across plugins and navigation content is provided through multiple specifications of org.eclipse.ui.navigator.navigatorContent extensions.

The tricky part is the triggerPoints and possibleChildren specifications. When is each used? Should you always duplicate content into both of these sections. The enablement element is actually provided so you can do exactly that.

The only true answer comes from looking at the source code. Since content extensions are provided through plugin.xml specifications and navigatorContent components are lazily instantiated, the underlying CommonViewer uses a content service that aggregates the plugin.xml specifications and instantiates them when needed. This is alot of book keeping but the code does this. The other actual navigatorContent sections are kept as descriptors until instantiated (as is common terminology and design in eclipse for lazily instantiated components).

The instantiated classes, once the providers are instantiated are fronted by 2 classes, NavigatorContentServiceContentProvider and NavigatorContentServiceLabelProvider. They implement ITreeContentProvider and ILabelProvider respectively (among other related interfaces e.g. IColorProvider). These classes lazily look for an extension specification that can satisfy its content request. So NavigatorContentServiceContentProvder asks the basic NavigatorContentService for extensions that can handle a specific element. The plugin.xml specification defines triggerPoints and PossibleChildren clauses that allow you to specify when a content provider should be "activated" for a specific element.

Content Providing: If you look at the code for content providing:


public synchronized Object[] getElements(Object anInputElement) {
  Set rootContentExtensions = contentService
              .findRootContentExtensions(anInputElement);

you see that the first thing the method does is ask the content service for extensions which can handle the specific input element. The method then iterates over all of the extensions asking each to provide elements. The union of these elements is returned. If some extension override others (through the override element in the plugin.xml specification) then those overriding extensions are used to generate elements. This story is also applicable for getChildren(). By looking at the code we see that both getElements() and getChildren() both utilize the triggerPoints specification. For getElements(), you can specify isRoot in a viewerContentBinding:contentExtension specification to force some content to be queried for root elements (the topmost level of the tree).

Note that there is a ICommonNavigatorContentProvider content provider interface that extends ITreeContentProvider with some initialization interfaces so you can access the plugin.xml specification and obtain your own configuration data of some sort.

For label providing, this is a bit different. The getText() method uses 


  public String getText(Object anElement) {
      Set contentExtensions =         
          contentService.findContentExtensionsWithPossibleChild(anElement);

which uses the possibleChildren specifications.

Another area of concern is when do the label and content providers become instantiated that are specified in the navigator content sections? Remember, you often specify 2 classes, one for providing content and the other for providing labels. If you combine these two into the same class as I often do, beware that the inputChanged() method is only called when the content part of the class is created NOT when the label provider is created! So if your combined class relies on inputChanged() to provide labels, you have lifecycle timing issues. Beware!

Comments

Post a Comment

Popular posts from this blog

quick note on scala.js, react hooks, monix, auth

quick note on scala.js, react hooks, monix, auth Reactjs hooks finally came out of preview in a recent version of React. scalajs-reaction has had support for hooks since they were in preview. React hooks seem like the hot new thing but for me the question is, do hooks help improve your code by improving maintainability, time to market, TCO, etc.? Let’s take a look using authentication as an example and employ monix , a reactive observable framework that also builds on cats . We will assume we are building a SPA. Does it improve your code and make your application & development experience better? Auth Auth processing can be complex. Many react auth examples you find in blogs like to show how to use “react-routing” and “auth” as a switch that determines which routes are protected or unprotected. Protected routes show application specific data. Unprotected routes show login content . Based on storing a “User” object in the browser session/local storage, th...
Read more

zio environment and modules pattern: zio, scala.js, react, query management

zio environment and modules pattern: zio, scala.js, react, query management This blog covers a zio-based fetch design for scala.js, react web applications. It heavily uses the zio “environment” feature to help motivate a point of view on the modules pattern in effect systems. At the end, I summarize some thoughts on ergonomics and complexity. This blog assumes a basic knowledge of zio and react. scala.js is just like scala so you mostly already know scala.js. This blog is a follow-on to previous blogs: https://appddeevvmeanderings.blogspot.com/2019/10/scalajs-react-fetcher-hook_48.html and https://appddeevvmeanderings.blogspot.com/2019/11/scalajs-and-react-suspense.html . I have been keeping an eye on and culling ideas from typscript/javascript fetching libraries that address query management concerns. The formulation below incorporates some of those concerns but does not try to comprehensively duplicate well established javascript libraries. I only care about ...
Read more

attributes with react and typescript.md

If you use typescript with react you may wonder what the right signature is for your “properties” interface. Obviously, your component will have few to many specific properties that reflect your domain. However, you may wish to also provide for the ability to add other attributes, such as those valid for a div property. In other words, you want to extend your props interface with that of the properties from a div element. How do you do that? There are really two issues: How do you extend your props interfaces How do you filter the props once you receive them to just those that apply. Extend Your Prop Interface or Use Sum Types It’s not uncommon to see interface Props { className ? : string yourProp ? : number } with the idea of using it in class MyComponent extends React.Component<Props, any> somewhere. If your component will have an outer div, you may also pass in a react element so that its configurable. But let’s say your outer element is a div and you wan...
Read more