Geertjan's Blog

  • July 1, 2010

Spotting the MVC Pattern in the NetBeans Platform

Geertjan Wielenga
Product Manager
When learning a new thing, one way to cross the hurdles thrown up by new concepts is to relate them to concepts you already know. The NetBeans Platform is broad and daunting at first, though much less so after you spend some time studying the Essential NetBeans Platform Refcard. Next, let's start relating some of the key terms, concepts, and API constructs to some concepts that we're undoubtedly familiar with, primarily, MVC.

Why MVC, in particular? Because that's a pattern very familiar to (Java) programmers and it is a pattern used throughout the NetBeans Platform. The nice thing about MVC is that it enables you to relate three separate things together as a single unit. So where, before, you had three separate unrelated items, you now, with MVC, are able to relate them to each other and, by understanding one, you understand all of them, at the same time. Handy, right?

So, here are some places where MVC can be seen in the NetBeans Platform:

  • FileObject (model), DataObject (controler), Node (view)

  • Node (model), ExplorerManager (controler), explorer views (view)

Well, with the above two, we've actually covered the majority of the NetBeans Platform already. Note that the "Node" classes (Node, AbstractNode, BeanNode, DataNode) play two different roles, depending how you look at it, first as the view, but then also as the model. (And FilterNode is an example of the decorator pattern.) The "explorer views" in the second bullet is one of BeanTreeView, or OutlineView, or ListView, or one of the other explorer views. When, confronted by the plethora of new classes you're confronted with when starting with the NetBeans API, the above simple division of classes might help in understanding how different parts relate to each other.

Other parts of the NetBeans Platform, such as its Wizard framework, can also be understood in terms of MVC. However, the above are the central ones to get comfortable with quickly.

Once you're comfortable with the above ideas, consider listening/watching NetBeans API architect Jaroslav Tulach talk about MVC and DCI in the context of the NetBeans Platform.

Join the discussion

Comments ( 5 )
  • Jesse Glick Thursday, July 1, 2010

    This is good to point out. One design problem I have seen again and again among people writing their first Node hierarchies is to mistake the view for the model. They write an action which should change the tree, and immediately try to call Node.destroy() to remove a node, or Children.add(Node[]) to insert some, or Node.Property.setValue to change some property, etc.

    This is of course absurd. Imagine you are writing a Swing app which manages airplane reservations. You have a JLabel that says "Economy". There is a button labeled "Upgrade to First Class" next to it, and now you have to write the ActionListener for the button. And you write:

    public void actionPerformed(ActionEvent e) {

    classLabel.setText("First Class");

    // wow that was easy...


    Hmm, maybe what you meant to do was actually buy a better ticket from the airline when the user clicked that button; and make the JLabel always display the current ticket class, using some kind of listener or event stream.

    The same is true of displaying anything with Node's. First think out your model. This could be the contents of a file, some configuration of files, some database records, Preferences keys, even just some POJOs that you do not plan to persist but will use shortly. The model needs to contain all the information you would use to reconstruct the entire node tree from scratch. It also needs to support listening to any kind of change.

    When the model is complete and tested, writing nodes is pretty easy - just display the model, and react to any changes you get. Typically one object (or path or ID etc.) in the model will correspond to a key in Children.Keys or ChildFactory, and the Node should last exactly as long as that object. Node's and related classes should generally have no instance fields beyond a reference to the appropriate part of the model, and maybe some listeners if not implemented directly.

    Writing actions should also be easy - adjust the model. The action should not have to refer to the Node's in any way.

  • Geertjan Wielenga Thursday, July 1, 2010

    Cool thoughts, thanks. Another way to approach the "Node is not the model" concept is to introduce the NetBeans API classes as WRAPPERS. E.g., the TopComponent is a wrapper for JPanels, while a Node is a wrapper for a business object. (A library wrapper module is also a wrapper, obviously, this time for external JARs.) As wrappers, what these classes do is wrap non-NetBeans objects such that they can, very simply, be included in a NetBeans Platform application -- without changing any of the objects that are being wrapped. (Similarly, the layer registrations for Action classes or, more correctly, the Action factory methods, are wrappers for AbstractActions and ActionListeners.)

  • Geertjan Wielenga Thursday, July 1, 2010

    PS: And a FileObject is a wrapper for java.io.File, with DataObjects offering access to the content thereof. (Here, the FileObject is the model for the Node, which again is a wrapper for the model, which is the FileObject.)

  • Jesse Glick Thursday, July 1, 2010

    I think the "wrapper" terminology is more confusing than helpful; you are mixing up some pretty distinct concepts, whereas "MVC" is fairly well defined outside of NetBeans.

  • Jaroslav Tulach Thursday, July 1, 2010

    If you want to draw some picture of such triads, feel free to add them to arch-usecase sections of dataloaders, nodes, explorer, etc. One picture can often replace thousands words.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.