While working on this multiview editor (a.k.a. Visual Editor in the NetBeans help files, tutorials, and other documentation), I encountered a lot of "boilerplate code". I find this pretty disturbing. I mean, if there are very large chunks of code that I need to simply copy and paste from one implementation of an API to another, doesn't that mean that there's something wrong with the API? One culprit in this department is the DataEditorSupport class. To me, this just seems like a big container for anything that an editor might need. It's potentially massive, with inner classes such as DataEditorSupport.Env, which I always have to use, but never have to modify. (This is also a big problem in the NetBeans module tutorials—if I know that people don't need to know all the details of what a class is for, because they're simply going to copy and paste it, then there's no need to describe it. But then, it looks really odd to have big chunks of unexplained code in a tutorial.) If we really want people to quickly pick up and use the NetBeans APIs, I think we should hide as much of these things as possible and only force developers to implement the methods that need to be customized. If a method or inner class does not need to be customized, why do I need to include it in my implementation?! I mean, I copied masses of stuff from Dave's simple implementation (shown yesterday) and then adapted it for my own purposes. I know that that's how it's always done, but still think that a lot of it shouldn't be necessary. So, to make things a bit more workable, I used a lot of code folds (I created a code template for these). That makes a huge difference, of course, as you can see below (click to enlarge):
Many cool things flow from using code folds—for example, when you hover your mouse over a code fold, a big pop-up appears with the content of the fold, so that you don't need to open the fold to see what's in it.
Interestingly, adding a multiview editor for a file type is really not very difficult (apart from the aforementioned massive blocks of boilerplate code). And the IDE is very helpful when you're making multiview editors—it provides the New Window Component wizard, which generates the window and all accompanying serialization files all in one go. (And, earlier on, the file type is also recognized by the IDE thanks to files generated by a wizard, in this case the New File Type wizard.) Once you've used the New Window Component wizard, you're off to a solid start. Implement the MultiViewElement (as will be explained in an upcoming tutorial, once I resolve the issues I encountered) and work with the aforementioned implementation of DataEditorSupport, and you're done. I'm making it sound easy, but it's pretty tricky (and without Dave's example code I wouldn't have got very far).
But the end result is pretty cool! A multiview editor is basically a visual form of code completion—you don't need to know all the elements and attributes (or whatever items the file type uses), because the component provides text fields and other components, such as comboboxes and drop-downlists (enabling some properties to be pre-defined, or mandatory, or both) for you to fill in. And, for relatively little work, including a multiview editor in your module for a new file type is sure to be an impressive extra to the more fundamental editor features, such as syntax highlighting. So, watch this space for the announcement of a new tutorial!