NetBeans: Form Editor Requirements

Version: 0.1

Authors:

Trung Duc Tran <trung.duc.tran@netbeans.com>, Sun Microsystems/NetBeans
Ian Formanek <ian.formanek@netbeans.com>, Sun Microsystems/NetBeans

Abstract:

This document briefly describes the requirements for the form editor, also known as the form module. This module adds support for visual GUI editing into the IDE.

Document History:

[2000-Aug-04] : version 0.1 : First version of the document

Contents:

1. Design Goals

2. User Interface

3. Storing Forms

4. Code Generation

5. Modularity

1. Design Goals

These are the design goals for the form editor:

• tight integration with the IDE, such that the functionality of the form editor fits well into other functionality provided by the IDE, such as compilation, debugging and, in general, the style of work with classes which are not developed visually

• provide full-featured visual development, which would be equal or better in functionality than other available commercial products such as Inprise JBuilder, Symantec Cafe or IBM's Visual Age for Java.

• not to introduce any proprietary solutions - most of the commercial builder tools force the user to use, to some extent, some proprietary classes, even when only standard AWT/JFC components are used during the visual development.

• thorough support for layout managers, as they represent one of the basic paradigms of the user interface of Java applications and applets

• provide support for Java Foundation Classes, but still allow development of forms based on AWT only

• generate Java code which would be as close as possible to that an experienced Java programmer would write by hand

• the implementation should be as modular as possible, make it easy to extend the functionalities in the future

2. User Interface

When editing forms the user interacts with four user interface components

• The form window displays the design-time representation of the form. It can be used for drag'n'drop manipulation of components and selection of components. The user can switch to real-mode, in which the GUI components are displayed exactly and behave as closely as possible to what should look like or happens at runtime

• The editor window displays the Java code of the form's class, which is partially generated according to the components used, their properties and events. There are two possible approaches of how to combine user edits to the source with the code generated by the form editor. The best option would be to give the user absolute freedom in editing the source and reflect the changes in the visual form. As this is a very complex issue, a compromise must be made in choosing the other possible approach - to protect some of the generated code from user edits in the editor and require the changing of this code by using the visual editing capabilities only.

• Component Palette is a repository of JavaBean components that can be used for visual development. The user selects the component from the component palette and add it to the form.

• The component inspector is a window which provides access to the components used on the form and enables modification of their properties and events. Here the components are displayed in a tree hierarchy to their container-component relationship in the form

3. Storing Forms

Every form (visually developed class) is stored in 2 files: the Java source file (with a .java extension) and the form file (with a .form extension). E.g. for a form named AboutDialog, there would be 2 files - AboutDialog.java and AboutDialog.form. Both the .java and .form files are important and must exist for the form to open properly in the form editor.

The .form file contains the hierarchy of components used, their modified properties, assigned event handlers and layout constraints.

The .java source contains the source code for the form which is always partially regenerated when the form is opened. The generated part of the file are marked as read-only in the source editor.

4. Code Generation

The form's class contains 3 parts, which are generated by the form editor:

• the initComponents() method, which contains generated code that instantiates all JavaBean components used, sets their properties and attaches event handlers to their events.

• One method per event handler - this method has the same name as the name entered for the event in the Component Inspector and takes parameters specified by the event - typically it is a single parameter with the EventObject subclass.

• The section for class variables declarations. For each component in the form one class variable is declared to hold a reference to that component.

5. Modularity

The internal structure of the form editor is modularized along the line of the above mention areas. There are four parts of the code

• the form model: information about the form is hold in this data structure.

• user interface: the user modifies the form model through the user interface

• code generator: whenever the form model is modified, the code generator is called to regenerate the affected java code

• form persistence: this part takes care of storing and loading the form model to/from file.

Among these parts the form model is the central one. All the other parts interfaces only with the model, not to each other. This makes it easy to plug in a new code generator or a persistence manager which would store the form model in a new file format.