Requirement:
The Eclipse
common navigator framework (CNF) is used as the basis for the NeXus Navigator within the
DAWN Science platform. The nexus navigator provides a focussed view on
nexus files, but in doing so removes the directory and project structure. However, more typically users need to focus on their nexus files within the context of their directory structure (often very deliberately set up and related to the experiment).
 |
Pre-existing navigator with directory structure flattened |
So the requirement is to show the existing directory (and project) structure but provide a filter such that only Nexus files are shown.
Solution:
Based on this requirement and the existing codebase, the actual work requires more deprecating code than writing it.
There was a specific content provider class written to flatten the structure. This and the corresponding label provider are no longer required: displaying files in the view is delegated to the default Eclipse resource content and label provider. That way the files always appear the same in any navigator view.
A filter is required, and the common navigator framework provides powerful extension point that allows it be implemented completely statically using xml. The filter automatically shows up in the view customizations but could be hidden if needed.
Rabbit holes:
Based on past experience, using expressions in Eclipse plug-in extension points can be tricky - if they don't work, it's not straightforward to debug why. Usually referencing the documentation coupled with a working example is a good starting point. Here's the filter expression for this case (which came with a certain amount of trial and error):
<filterExpression>
<and>
<not>
<adapt type="org.eclipse.core.resources.IFile">
<test
property="org.eclipse.core.resources.extension"
value="nxs">
</test>
</adapt>
</not>
<adapt
type="org.eclipse.core.resources.IFile">
</adapt>
</and>
</filterExpression>
 |
Pre-existing navigator with flat directory structure flat |
In particular, note it is best to use the
tag rather than to ensure the filter works not just for files but anything masquerading (or adapting) to the IFile interface.
Testing:
There is no Java code provided that requires unit tests. Using the extension point takes advantage of the pre-existing testing and repeated use by the open source community. The expression can be verified and so tests for the navigator are naturally rolled into tests for upcoming features intended for the navigator.
Resources:
- Common navigator framework - http://wiki.eclipse.org/index.php/Common_Navigator_Framework (the blog resources are particularly useful)
- Eclipse expressions reference - http://wiki.eclipse.org/Command_Core_Expressions