Extensible Node Hierarchies for Custom Project Types
Since NetBeans 6.0 you can extend existing Project Types by registering a NodeFactory as described here:
http://platform.netbeans.org/tutorials/60/nbm-projectextension.html
That’s cool, but what about your own project types, not only the ones predefined by NetBeans? So if for example you defined your own project type as described here:
http://platform.netbeans.org/tutorials/nbm-projecttype.html
When you look at the registration of the NodeFactory in this tutorial, the NodeFactory is registered in folder “Projects/org-netbeans-modules-web-project”. Where does that magical string come from, and how do you provide your own? The string looks like a module id, which makes sense since the granularity you’d choose when defining project types is most likely module level. The API Doc for NodeFactory has the answers:
“Project types wanting to make use of NodeFactory can use the NodeFactorySupport.createCompositeChildren(org.netbeans.api.project.Project, java.lang.String) method to create the Project nodes’s children.
public class FooBarLogicalViewProvider implements LogicalViewProvider {
public Node createLogicalView() {
return new FooBarRootNode(NodeFactorySupport.createCompositeChildren(myProject, "Projects/org-foo-bar-project/Nodes"));
}
}"
So when you want to have this extension mechanism in your own project type you simply use the helper Method
NodeFactorySupport.createCompositeChildren(Project project, String folderPath).
Just pass in a string to identify the folder, e.g. the name of the module defining your project type, and the API will take care of the rest. Looking at the custom project type tutorial you would change the TextNode in the LogicalViewProvider to:
public TextNode(Node node, DemoProject project) throws DataObjectNotFoundException {
super(node, NodeFactorySupport.createCompositeChildren(project, "Projects/de-eppleton-project/Nodes"),
//new FilterNode.Children(node),
//The projects system wants the project in the Node's lookup.
//NewAction and friends want the original Node's lookup.
//Make a merge of both
new ProxyLookup(new Lookup[]{Lookups.singleton(project),
node.getLookup()
}));
this.project = project;
}
As a result you can now register new NodeProviders for your custom project type under the path “de-eppleton-project” either in the layer or use the Annotation:
@NodeFactory.Registration(projectType=”de-eppleton-project”)
public class AdditionalNodes implements NodeFactory{
@Override
public NodeList<?> createNodes(Project prjct) {
AbstractNode root = new AbstractNode(Children.LEAF);
root.setDisplayName(”additional node”);
return NodeFactorySupport.fixedNodeList(root);
}
}
And the result looks like this:
). I’ve invited Zoran Sevarac and Jaroslav Tulach to join me and I’m really looking forward to this. We’ll discuss topics like how to identify module boundaries, API design, how different module system ( like NetBeans Platform and OSGi )deal with loosely coupled communication and even if and when we need a module system, and when it’s an overkill. It will be a huge effort to boil this down to session format, but I promise we’ll do our very best to capture the essence and it will be worth your time.
