Update: The utility, described in this blog post has moved to it's own project page.
Every Desktop application pretty much needs a GUI. No problem so far. The trouble starts however, when components have to be arranged visually in a container. The preferred method for doing this is in Java, is to use a layoutmanager instead of specifying absolute pixel coordinates for component placement.
Trying to build complex dialogs by hand using layoutmanagers is a chore at best. You basically have two options here: Either build dialogs by nesting containers, which are each layed out by simple to use layoutmanagers or just use one flexible layoutmanager like
java.awt.GridBagLayout, which is difficult to handle. Both ways are time consuming and prone to error.
Most people therefore go for the the third option: Use a GUI builder to hide the complexity. A solution, I personally was never very fond of. Every GUI builder, I tried up to date fell short for me in one or the other way:
- GUI builders are often part of an IDE. I do not really want to switch IDEs, just because of this feature.
- No ease of use. If I have to invest the same time for learning how to use a tool and produce results with it, then without it, I can as well skip the hassle.
- Ugly code. Generally the generated code either violates your coding guidelines, requires some extra classes to be bundled with your application (license issues!) or is cluttered with undesired functionality.
- The correct way to develop an application is to write the core functionality first, then add the UI controls and finally lay them out. GUI builders often do it in the opposite way by asking you to layout the controls first and afterwards offer you to hook them up to the core program. This always reminds me often trying to package a present by starting with choosing a wrapping and then trying to figure out what to put in it. Of course, creating the GUI first and then trying to model the core after it also ends in a disaster, once the customer decides, that some controls should be put in a different place.
Back to the drawing board, then. Time to reconsider methodology. Visual layout should be the last step in application development. People change their mind all the time about which button should go where and finding the best arrangement for components in a container is a trial and error process anyway. Scrap and redo of the visual layout should therefore be as easy as possible to support rapid prototyping.
The logical layout of a container should be describable by some meta language, from which the actual Java code can be generated. A suitable metalanguage is HTML, or more precisely it's table construct, which can easily be translated into
java.awt.GridBagConstraint objects for configuring a
java.awt.GridBagLayout. HTML has furthermore the advantage, that the visual layout of a GUI class can easily documented directly in that class's javadoc header (and/or extracted from there).
The program, attached to this blogentry is able to accomplish the above mentioned task. It may be started from a commandline with:
java -jar table2gridbag.jar table.html
It will then generate an according snippet of Java code and write it to stdout. Code generation can be influenced by specifying the following (optional) properties:
indent Indent string (default: "\t").
cname Name of the variable for the GrigBagConstraints object.
lname Name of the variable for the GridBagLayout object.
container Name of a container object to layout.
Some sanity rules, that must be followed:
- Table cells must always be rectangular.
- Table cells must neither overlap nor have gaps between them.
- At least one cell must have width and height (in percent) specified.
- HTML code must be standard conform.
- Only one HTML table per file allowed, tables may not be nested.
- The cell content must be the name of the object to put in this place.
Not following these rules will either produce junk code (e.g. not specifying widths, will result in cells without weights and therefore the layoutmanager will clutter all components in one tiny space) or throw an exception.
Example HTML and skeleton Java files are included in the ZIP file.
Conclusion:The GridbagLayout works very similar to HTML tables. Layouting an HTML table however, is much easier then configuring a GridBagLayout object. Furthermore, the logical layout of the application's GUI should be described in the projects documentation anyway. Table2GridBag allows to extract this specification and transform it into Java code, that configures a GridBagLayout accordingly.