Form Editor: Top 10 Issues
Author: Tomas Pavek | Started on: 04/25/2001 | Version: 4.0
Document History: $Revision: 1.16 $ | $Date: 2005/04/28 13:57:08 $ | CVS
This is a brief list of current issues and things that we feel should be solved/done in
the Form Editor.
The list is one of the base sources for planning new features for next releases. Comments are welcomed on nbusers
or nbdev mailing lists.
Each item in the list is marked by *, ** or *** providing a rough estimate
of total amount of work needed to
solve the issue (* stands for rather simple issue, *** for a complex one).
Contents
1. Getting rid of form files
2. Form 'designer' improvements
3. Architecture improvements
4. XML Persistence
5. Support for javax.swing.Box
6. Specifying TAB order of components
7. Support for actions
8. Setting Look & Feel of designed form
9. Nature layout support
10. Extensible forms
Other
The feature we have been thinking about probably for the longest time is so
called "two-way editing" of forms' java code. It is one of the most wanted and discussed features. It
means getting rid of the special XML .form files and reading/writing the forms
just from/to the java code. This is very resource demanding feature, it is not
clear whether it will ever be implemented. But there are several variants of
how to get along without the .form files. They represent significantly different complexity and resources
required.
- True two-way editing -- with no .form files, no guarded blocks in source
code, full real time updates between the source code and the form model.
- Limited two-way editing -- the source code would be parsed only once when
the form is opened, then there would be just one-way code generation (no synchronization of
the form model from source
code); this would mean still
no .form files, but some kind of protection of the generated code would be
needed to avoid user modification.
- Importing source code -- the . form files and guarded blocks would be still
used as now, but there would be an import tool being able to create .form
file from java source file.
The form designer has very nice WYSIWYG capabilities but limited visual
layout editing features. E.g. the GridBagLayout customizer, which is one of the
most user-rated features, is opened in a separate window. It has nice dragging capabilities for the
layout, is smart, but very
restricted in component presentation and other editing operation (it is just a
specialized view). And it is also hard to find for beginners (for whom it is
most useful).
We need some kind of built-in layout customizers and other designers (menu, bean connections,
etc).
To achieve this we must create some infrastructure for being able to use
special designers in the form editor window (e.g. for layouts, menus, non-visual
components, connections etc). Then reimplement the GridBagLayout
customizer using this framework, and possibly also create customizer for SpringLayout
from JDK 1.4 or FormLayout from JGoodies. This is one of the top current requirements on form editor.
Maintainability and
further development of the form editor is difficult. The problems are: wrong design of some parts, excessive internal
dependencies, various hacks and unfinished rewrites, limitations in metadata expressiveness
and code generation, visual designer limitations, etc. There are also lots of
requirements for reusing the form editor, extend it and build other tools on it.
There are no reasonable APIs for accessing form editor functionality and possibility to extend it
(metadata hierarchy, persistence manager, code generator, etc). However these
requirements are not priority for us, improving the architecture in this way
would help both internal and external developers.
There is lots of potential for improving the architecture in terms of:
- modularity (better defined and
independent parts of form editor),
- extensibility by other modules
(layout support, code generation, persistence, metacomponents, nodes),
- APIs
(for accessing form editor functionality and making the extensions),
- metadata model
(cleaned and improved metacomponent hierarchy, reinvented "synthetic
properties", more general "code like" metadata structure).
At least the modularity and metadata model improvements are vital and would
provide a ground for significant user feature enhancements.
Form editor uses its own proprietary XML format for storing the form
metadata. However the two-way editing approach using the java code eliminates
the need of any additional persistence format, there are several reasons to
support alternative forms of persistence:
- interchangeability -- allowing to import/export forms between different
IDEs,
- separation of the UI from the code -- i.e. all the UI data stored
separately, not built by the java code, just read from a file at runtime,
- platform independence -- there can be a universal format describing UI
elements independently on target platform (e.g. XUL).
At a minimum, we should support export/import using the JDK's standard XML
persistence (introduced in JDK 1.4). It has the advantage that stored components
are very easy to read, so we could allow the user to create forms stored this
way instead of generating all the java code. The java source would just contain
simple code for deserialization the form using XMLDecoder.
However, such forms would be rather simplified as not all metadata of the form
editor's model can be expressed in this format.
People often ask for support of javax.swing.Box features -- for using
"glues", "struts",
and "rigid areas". These are special components with various resizing constraints which
facilitate design of containers based (not only) on BoxLayout. They
are standard part of Swing, very useful -- and hardly substitutable by anything
else in the form editor. People often need to give up visual editing of given
container and code it by hand.
The main implementation problem is that the components are not standard beans
(they are created by factory method of Box) -- a special way of components creation and code
generation is required. The improved beans repository should enable to install
also such special components to the Component Palette.
See also issue 8304.
Defining TAB order is important for accessibility of designed forms. This
missing feature could be hopefully (and finally) implemented using the new
focus subsystem in JDK 1.4. Other accessibility support issues have been
already addressed in 3.4 release (see
Accessibility Support docs).
There was a discussion (see
Suggestion for better support for actions on nbdev mailing list) about
possible support for creating actions in
Form Editor. The goal would be to enable the user to create and customize his/her own actions (probably
javax.swing.AbstractAction subclasses) and attach them to components within the form.
This way the user would benefit from the Swing's action framework.
The support would be most probably restricted to innerclasses actions, global actions (as
standalone classes, shared by more forms) cannot be treated.
There are more and more Look&Feel implementations available in the world.
Form editor should support development of forms for other Look&Feel (not
just the default Metal Look& Feel or the one used by the IDE). The developer
should be able to see the look directly at design time and it should be used for
the form also at runtime.
The
implementation of this feature (having the form use other L&F than the IDE) is kind of hack, it's not clear whether we
can manage it to work properly. Some investigation is needed. Besides presenting
the form in the IDE, form editor should also produce forms running in the given
Look&Feel -- i.e. to generate code setting up the Look&Feel.
All users would benefit from a layout design support that allows to naturally design the GUIs without worrying
about the layout managers, constraints, parameters, but still creating good UI (i.e. not absolutely
positioned/sized).
When one form extends another, it is not possible to access and modify the
parts inherited from the superclass. The same is not possible for forms added to the designed form.
This is about visual inheritance of forms, and using forms in forms.
Form Editor could be capable to load the form metadata for inherited or contained forms and use
it to customize additionally the appearance of these forms in the designed
form (without changing the originals). This would require to make appropriate
extensions of the metadata structure (e.g. we are not able to deal with
non-empty superclass forms yet) and code
generation capabilities. For creating "extensible" forms by the user
there could be a special template (e.g. with variables predefined as protected).
See also Forms inheritance and extensibility
from nbdev mailing list.
There are lots of other missing features, e.g.:
Allow changing code in guarded blocks **
[Usability]
Grouping components into a container *
[Usability] It's difficult to insert a new container in the hierarchy when it is needed
to group some components additionally (or e.g. place some component already
added to scroll pane).
There could be a "Group Into" submenu in context menu for visual components
which would display available container types. The selected
container would be added instead of the components which would be
moved to the container. This is simply a shortcut for "add container and
cut/paste components" operations. See also issue 7533.
Indexed properties **
[For professionals] Indexed properties are not currently supported. It's a question how much they
are missing, but we should support them in the future anyway.
There are two types of indexed properties according to their setter/getter
methods: arrays, and those being set/retrieved one by one using some index parameter.
The arrays are much easier to handle with -- they work even now if there's
suitable property editor (e.g. StringArrayEditor). But we should cover both
types generally -- create some special property editor (customizer), and also
solve the persistence issues.
Extended in-place editing *
[Productivity] In place editing doesn't work for AWT components now. A special support for
JTabbedPane and TitledBorder could be also added.
Java Look&Feel compliance **
[For beginners] Form editor could help the user to create JLF complying
forms by presetting components' insets, resizing parameters, etc. Feature
suggested originally for GridBagLayout customizer, needs more investigation.
Professional Features **
[For professionals] Our IDE provides mature features for real production UI-development -- e.g.
full internationalization and accessibility of designed forms.
This is a significant competitive advantage. But the support lacks several
important things to be perfect, e.g. internationalization of mnemonics and
setting TAB order of components (part of accessibility). We should put down a
list features that are a must for professional work and make sure they are
supported.
Nature layout support ***
[For beginners] A bit "wild" idea that there could be a layout
support allowing the user to naturally design the GUIs without worrying
about the layout managers but still creating good UI (i.e. not absolutely
positioned/sized). Such a feature would be valuable mainly for beginners.
But would require to implement an abstraction level over the AWT layout
system which is now present in every aspect of making the design using the
form editor.
Tough to even design the behavior, not even think about the
implementation.
Event handler body creator **
[For beginners] The beginner user often does not know how to write code that performs certain tasks (opening a file, printing,
etc).
Custom borders
[Extensibility] Should be possible to add custom borders to palette and form
editor should handle them like the standard borders (show them in the border
editor etc).
