---

After NB6 UI Editor Ideas (Under construction)

This page contains different ideas for the NB UI Editor (form/Matisse) after NB 6.0.

Update or possibly rewrite the UI editor file format

The current file format of the .form files limits us in different ways. But mainly

• There is currently no mappings between the .form file and the .java file
• There is currently no mappings between the .java and the .form file
• Syntax could possibly be better

If nothing else maybe the old format can be updated again to provide better support for different situations. The current strategy makes refactoring rather difficult. The reason being if there is custom code contained in the .form file it is hard to tell when it should be changed based on changes to the .java file. This is caused by the model of the .form file not reflecting Java information other than just as text which can be put into the .java file which the user has edited. Event handler and property names are the easy part as those names are kept in the .form file and can be looked up more easily.

If the .form file kept some type of a map which was updated when the Java code was changed this might help. That would require a document listener and every change to the .java file would mean something was updated in the .form file, or at least the model until the changes were saved. Then these mappings which give offsets and other information about the Java file and model could be used in refactorings to exactly get back to sections of code in the form model which come from changes to the .java file. This would matter for custom code only and custom code would be the only things mappings would be needed I think at this time.

Document the form file format and all possible elements

Currently if one loses their .form file they are just dead in the water as far as using the visual editor again in NetBeans for the form they accidentally deleted. Were it better documented then one could just walk through the documentation and rebuild their form by hand. This would of course be hard to do when many components are in the file, but it would help. The documentation could then be used to come up with process to automatically regenerate the .form file.

UI Import Tool/Feature

There is currently a project called the FormGenerator by Vi Ho which does this some what, but it depends on certain patterns being in place to work correctly (I think). Vi may be able to help more. The files can be found on http://contrib.netbeans.org

Tomas Pavek knows of another project under way. He is to find out more about it. He will undoubtedly write information here about it.

Anyways, this is something which is needed. There are different patterns used in the world. We should be able to import many of them. Known UI patterns or applications which have their own method of production UIs:

• JBuilder - It and JDeveloper use the same patterns I think, but would have to confirm. Some differences might be specific code for Layout support.
• JDeveloper - I know JDeveloper uses specific patterns to make .java files editable in its UI. Oracle also provides specific Layout wrappers which treat different Layouts like JavaBeans or a particular interface (one or the other). This includes the FormLayout from JGoodies. The Layout stuff is important because it would have to either be converted to the Swing Layout (Free Design) or FormLayout would have to be added to the IDE. Support for some of the commonly used 3rd party Layout managers might be a good idea though.
• IntelliJ - The last time I tried this functionality they had their own .form file type format. This was when their UI editor was in its very early stages. I'm not sure what they do now.
• Eclipse VEP - I think this is code pattern based, but not sure.
• NB UI editor/Matisse - With lost .form file not edited by hand after .form file lost
• Generic hand edited UIs - The most difficult, but we may be able to provide a wizard which helps walk the user through some processes which may enable us to import any arbitrary code as long as supported Layout managers are used or we can some how provide a valid alternative.

Guarded blocks and .java file editing - Possibly time for a new model

There seem to be 2 ways of handling this. One is to use the new Java model and hook into the Java file keeping the code in certain patterns and using those patterns to build the UI. This is what JDeveloper and JBuilder do.

The user can hand edit the file, but if they mess up the patterns the UI editor will break and they have to figure out how to reformat their code to make it work. In those IDEs if one messes up the code it can be a very big headache to fix it sometimes if the code is very complex. It is a very trial and error approach.

Another approach is to use a pure .form file, add another package to the users compile time libraries, and create an annotation library. We couldn't support Java 1.4.2 though without the use of something like RetroWeaver at build time to process the annotations and that is given it can support compile time annotations. In 1.5 we would have to run apt and in Java 1.6 we would have to possibly add extra parameters to the javac calls unless it processes the annotations seamlessly.

We would have to then create a compile time annotation library which would match a new form file format which would contain all the Swing information. The user would not actually touch Swing code by hand except during customizations as happens now. The main difference would be the user would *not* see the Java code in the editor. The actual Swing Java code would be created at compile time based on the information kept in the .form file, and the .form file could be designed with refactoring in mind, so all the class names and method names would be kept

Though of course the custom user code still presents a problem in that we don't have a .java file to process during refactoring as other modules do. We could though during a refactoring use generate .java file and generate extra information into the source code such as annotations which could be used to map the code back to the current .form file...exact lines and all.

This would make refactoring much easier, though I'm not sure about performance of large files. This could be something we do in the background constantly. We constantly add changes to some Java files in the cache or some temp space which we use during refactoring. When a project opens however we would have to check time stamps and file SHA1 hashes and rebuild any files we may need in the background. Needs more design and thought obviously, but a good start to an idea or option, and maybe even if we don't use the full idea could be used to improve refactoring for the current form model.

The second option is more along the lines of what Microsoft and Borland do with some of their products. They keep extra information in a separate resource file for the UI. That resource file is then processed. The difference would be that these resource files will work with any Java 1.5 or 1.6 JDK as annotations are standard. It keeps the user from editing the .java file and more aware of the .form file because they'll more likely notice the .java file has only the code used in their event handlers or some of their own code. Event handlers could then be simple methods with the correct signature and they user can choose which one fits an event at any time from a drop down.

The main problem I see is the second option uses compile time annotations and much of the code doesn't exist for the rest of the modules to use to see properties etc in classes made in the UI editor though, if the compile time annotations are processed and signature data is kept in the cache then this should be able to work. It obviously has a lot of things which need to be examined.

The first option is good in that everything is in the .java file. Also, there are no guarded blocks, though they could be used to better guide the person in developing their application. They could exist and the user could customize the code, but they would have to, while in the IDE, ask it to allow them to do so, and then as we know they are editing fragile code can popup hints some how to keep them editing it correctly, and if the patterns are documented well that shouldn't be too much of a problem. The down side is the same as for JDeveloper and JBuilder though through guidance and good documentation this can be made better I believe.

Generic Layout Support

There used to be generic layout support classes. These may still be viable, but some how there needs to be a way of providing hooks so that generic Layouts could be used by the editor in general. Right now one can "customize" a layout, and this can get the person into the layout of the components, but it seems some type of an API could be designed based on converting from the coordinate space of the UI editor. Anyways, this is just a thought at the moment so one could create a module, the UI editor grab on to some type of a provider, and that provider use the new generic layout provider support. The UI editor would then be able to convert the coordinate space information into information to use to setup the layout using the provider.