By default, both the new checkboxes are unselected so that by default you get exactly the same code as before. Both cannot be selected at the same time, because the palette that is created is currently specifically for editors (e.g., you get an Editor Palette Item XML file, with the sample code snippet above as the body that will be added to the editor when you drop the item), while the OpenSupport implementation assumes that you'll be creating a TopComponent at some point. If you choose to let the wizard create a palette, then you'll get a PaletteFactory.java class, an XML file that conforms to the Editor Palette Item DTD, various entries in the layer.xml file, a new dependency in project.xml, and two images (one 16x16 pixels and the other 32x32 pixels) that can represent the item in the palette. As soon as the wizard is complete, you can install the module and then your new file type will have a new palette, with one item, so that you (as the palette developer) will be able to see how to create other items for your palette. if you selected "Open into TopComponent", you'll need to create a TopComponent at some stage, and then tweak the generated OpenSupport implementation slightly, but those bits are already in the generated code, just stubbed out, with lots of explanatory comments. I always find the OpenSupport class, despite the fact that you only need a very few lines, quite tricky to implement. There are lots of little things that can go wrong and the code is a bit dense. Now, with this wizard, even though I need to tweak things afterwards (because the TopComponent is created separately), I at least have all the information I need (i.e., via comments and code snippets) right inside my module. One cool thing I've done so far with these enhancements is... I generated an OpenSupport implementation and then used yesterday's enhancement to generate a TopComponent with the "Enable Visual Library" checkbox selected! As a result, now I can open a file into a Visual Library scene, without having done almost any coding at all!
It really isn't hard to make these kinds of changes to the NetBeans API wizards. First, as stated yesterday, check out apisupport/project. (Note that this is different to apisupport. Make sure you check out apisupport/project, which is a module in itself.) Then find the wizard you want to change. For example, the loader package defines the New File Type wizard. Here's what the package looks like, at least, here's what it looks like for me, since I've made several changes:
Just create a template for the class that you want to have generated, then look in the iterator class for how other templates are created. And there are a lot of really powerful utility methods that you can call. All you need to know are the parameters to send to the utility method, which isn't hard to work out if you look at the rest of the iterator code. And the utility methods are really clearly named, so you know what to do with them. Have a look at them here:
Not bad, right? Methods for adding dependencies, entries in the layer.xml file, attributes, bundle settings, and so on. Really cool. An entire framework for NetBeans API wizards. So, even though it might take a bit of work, at least initially, to enhance these wizards, once you've done so you'll never need to create boilerplate code again. After all, the basis of every editor palette is the same, the basis of every OpenSupport implementation is the same. And there are many such scenarios that are identical for each module. And how many times have you had to create those by hand? Seems like a lot of unnecessary work. Invest a little bit of time in enhancing the apisupport/project module for your environment by letting the wizards generate your most commonly typed code and then you'll be able to use them to generate more and more of the code you need from that point on. After all, people using these wizards are NetBeans API implementors anyway, so it's not such a stretch to suggest that those who want to use the NetBeans APIs can hone their skills by extending the existing code generators (and adding new ones) for their specific subset of boilerplate code. Hence, my suggestion is, whenever you find yourself typing the same lines of code over and over again, you need to wonder whether you shouldn't try to enhance one of the wizards to do that work for you. Yes, you'll have a customized version of the apisupport/project module, which means that when a new release of that module comes out with NetBeans IDE, you'll need to manually upgrade or do something if you want to make use of new enhancements in the official release, but that's life. Every advantage has a disadvantage.