Monday Nov 24, 2008

Sharing ExplorerManagers Between TopComponents

The NetBeans ExplorerManager class is great—it lets you display the same set of nodes in multiple explorer views while synchronizing the selection. In other words, if you select a node in one explorer view, it will automatically also be selected in another explorer view.

An explorer view is placed on a TopComponent that implements ExplorerManager.Provider, with the ExplorerManager's root context being set to the root node. Then everything happens magically from there thanks to the ExplorerManager: each explorer view in the TopComponent will have synchronized selection management for the node hierarchy. But... what if the explorer views are in DIFFERENT TopComponents? Below is a perfect example. The explorer view on the left (BeanTreeView) displays nodes, while the explorer view on the right (PropertySheetView) presents a different view on the same nodes, which should therefore be synchronized with each other:

In other words, the explorer views are in different TopComponents. If, as normal, you instantiate the ExplorerManager in each of the TopComponents, you have TWO ExplorerManagers... which means you will have no selection management between the nodes in the different explorer views.

Here's the solution to this problem.

  1. Create a new Java class that defines an explorer manager:
    import org.openide.explorer.ExplorerManager;
    public class MyExplorerManager implements ExplorerManager.Provider {
        private ExplorerManager em;
        public ExplorerManager getExplorerManager() {
            if (em == null) {
                em = new ExplorerManager();
            return em;

  2. Create a new folder (with any name you like) in the layer.xml file and then register the above class there:
    <folder name="ExplorerManagers">
        <file name="org-my-demo-MyExplorerManager.instance"/>

    At runtime, the ExplorerManager is available in the filesystem and any module in the application can make use of it.

  3. In each of your TopComponents, implement ExplorerManager.Provider, exactly as you would always do. However, instead of creating a new ExplorerManager, get the one above from the filesystem via the Lookup. For example, this is the PropertiesTopComponent you see above:
    private ExplorerManager em;
    private PropertiesTopComponent() {
        setName(NbBundle.getMessage(PropertiesTopComponent.class, "CTL_PropertiesTopComponent"));
        setToolTipText(NbBundle.getMessage(PropertiesTopComponent.class, "HINT_PropertiesTopComponent"));
        em = Lookups.forPath("/ExplorerManagers").lookup(Provider.class).getExplorerManager();
        em.setRootContext(new AbstractNode(new WordChildren()));

    Note the line in bold, of course, which looks in the specified filesystem folder for a class of the required type.

  4. Do the same for all the other TopComponents that need to have the same ExplorerManager handling the selection for their explorer views.

What's nice about this solution is that it leverages some of the central tenets of the NetBeans Platform: selection management, explorer views, nodes, lookup, filesystem... It's a perfectly NetBeans-centric approach to this problem. The most interesting part is the registration of the ExplorerManager in the layer.xml, because it is yet another example of the cool things you can do if your application has a filesystem. And all NetBeans Platform applications automatically have one of those for the whole system.

Warsaw on the NetBeans Platform!

Karol Harezlak, Toni Epple, and I spent the last two days with Jacek Sroka and his group of students from the Faculty of Mathematics, Informatics, and Mechanics at the University of Warsaw, delivering the NetBeans Platform Certified Training. Here's the whole group at the end of the training:

(I'm not in the picture because I was holding the camera that took it.) For the first time, despite being limited to our two day parameter, we extended the program to include 3 hours of workshops on both days. So, instead of the standard 5 hours, we did 8 hours both days, starting at 9.00 and ending at 17.00. This was certainly a better solution than previously, where hands on work was left until the end of the two days. However one looks at it, two days isn't much, but on the other hand, we're not fulltime trainers and are unable to make much more than that available (i.e., Karol is one of the engineers in the Mobility team and I am a technical writer in the Docs team). But, this solution, of inserting 3 hours of workshops (i.e., after/during three of the presentations, the students were able to do some exercises to begin working with some of the concepts that were introduced), is a pretty nice compromise.

Here you see part of the group intently listening to one of the presentations:

But it wasn't all hard work for Karol, Toni, and me. On the evening of the first training day, Jacek Laskowski invited us to a party for the Eclipse Demo Camp that was being held at the same time. We had a really good time, thanks Jacek and others from the Eclipse Demo Camp. Here you see someone we met (from Gdansk, who was also at the NetBeans Day there some weeks ago), Toni, and me at the party:

And here you see some more of the scene at the party:

Next day it was back to school for everyone. By the way, it was really great to have Toni participate: he did the presentation on the System FileSystem and also on the Visual Library (for the first time, this was included in the course). He's really excellent: he doesn't work for Sun and is therefore a more credible NetBeans advocate than I or Karol can be. He has his own Java Consulting and Project Outsourcing company and knows the NetBeans APIs from having worked with them at a company where he led the design and implementation of a NetBeans Platform application. He's also very enthusiastic about the NetBeans Platform and its APIs and can explain how they work very well. Here's one of his slides, during the Visual Library workshop:

Finally, the students received their certificates. Here's one of them, Tomasz Frydrychewicz:

I'm looking forward to going back to that university some day soon. Some of the students are going to be doing their university thesis about the NetBeans Platform. Jacek said that in a future course there, there could be completely new people to the course, so we could start again from scratch. We could also go further into the NetBeans Editor APIs, because the students seemed particularly interested in that.

Students who were on the course and who want to get the next level of certification will be working on NetBeans modules (either for NetBeans IDE or some other application on the NetBeans Platform). They'll need to go through a quick registration process to get a account, after which they'll be able to register at this mailing list (where all the NetBeans Platform experts are found):

Then, before beginning the work on their idea, they'll write to the mailing list to see if others aren't working on it already. If others are working on their idea, they'll potentially be able to join someone else's project, which would be very cool too. Looking forward to hearing their ideas!

By the way, the student from a previous course (in Germany) who is working on 'batch refactoring' for NetBeans IDE is making some great progress, read all about it in the issue below:


Geertjan Wielenga (@geertjanw) is a Principal Product Manager in the Oracle Developer Tools group living & working in Amsterdam. He is a Java technology enthusiast, evangelist, trainer, speaker, and writer. He blogs here daily.

The focus of this blog is mostly on NetBeans (a development tool primarily for Java programmers), with an occasional reference to NetBeans, and sometimes diverging to topics relating to NetBeans. And then there are days when NetBeans is mentioned, just for a change.


« November 2008 »