Unmodified, Swix takes as inputs

• an XML file describing the layout
• a Java "starter" class that instantiates all of the widgets and calls Swix

We add an aspect file to the above, but the Java starter class file is now simple enough to make with a preprocessing utility. We also have a pre-processing utility that creates a "skeleton" aspect that the users would flesh out with behavioural code.

We plan to modify Swix so that instead of making JComponent instances, it makes calls to our wrapper classes. At this point, it makes XButton, XTextField, and XLabel instances instead of JButton, JTextField, and JLabel instances.

• Lit review(?)
• Tools review
  • not doing Java output
• Possible approaches to problem
  • straight LTW -- wasted a lot of time, not an option => must have wrapper -> must create wrappers, must change all swix code to call the wrappers
  • different class for each instance
  • different dummy method for each instance
  • have pointcuts driven by the arguments

Using Aspects to build GUIs

Our goal in this project is to separate out the visual description from the behavioural description. We want to allow users to write

• XML that describes the layout of the GUI
• aspects that describe the behavior

We had originally thought we would take XML and aspects as input and create AspectJ output, which would then undergo a separate compilation step. However, we found that tools exist that would eliminate the need for a second compilation step: XML + aspects on the input create an executing GUI instead.

In the rest of this paper, we will discuss

• tool selection
• approaches considered
• status update

Tool selection

We decided very quickly to use AspectJ. "Working on the bleeding edge" is a euphemism for "all the tools break", and we felt that it would be far safer to use a language with significant in-house expertise than one that did not. Thus we did not consider languages like AspectWerkz, CAESER, or EOS.

We found a number of tools that took XML as input and either generated Java as output or displayed a GUI:

• The documentation for jxmlguibuilder was entirely in German. While Sebastian is fluent in German, Ducky can only read it with great difficulty, and Sukesh does not know German at all. The project also looked abandoned.
• The Java Gui Builder and JXUL had documentation in English, but the documentation was very poor.
• Luxor is pretty much the Cadillac of XML->GUI translators. It uses XUL as its XML dialect, and has a very rich and active development community. However, Luxor looked excessively complicated. In addition to the XUL translation, it has a web server, a portal engine, a template engine, a Python interpreter and more. We did not want to have to wade through all the extras in order to get at the XML translation kernel.
• Glade is a robust project with a GUI interface to generate the GUI code, but unforunately uses GTK widgets and not Swing ones.
• Koala seems to be built on Java Beans, which seemed wrong for our project.
• SWI XML (AKA swix) seemed to have @@@ blah blah -- more here
• Thinlet seemed very similar to Swix, but not as good.
• gui4j was limited in number of attributes for objects is limited.

After careful evaluation, we decided to use Swix as our XML translator.

Approaches considered

• We do not have source for the Swing widgets. This means that we cannot do compile-time weaving of elements like JButton.
• Each instance of a widget can have different behaviour, while aspects work on a class-by-class basis.

Load-time weaving

Furthermore, we found a reference [Xerox200?] that said that load time reweaving of the java.* and javax.* classes was not possible. (We theorize that it is not allowed for security reasons.) We thus decided that discretion was the better part of valor, and instead put wrapper classes around the Swing widgets.

Instance-level aspects

One thing we considered was to make a different class for each instance, with each class subclassed from the "true" class. For example, we could have e.g. JButtonFahrenheitButton and JButtonCelsiusButton both be subclasses of JButton. This looked ugly: we would need to programmatically generate the wrapper classes on the fly; in order to write the aspects properly, the developer would need to understand that dummy classes were being built with ugly names.

Similarly, we considered inserting a dummy method in the wrapper class(es) to correspond to each instance. The only function of the dummy methods would be to give the developer something unique to the instance that they could then exploit with a pointcut.

Instead, we realized that since we had to use a wrapper anyway, we could pass an instance identifier to a wrapper's constructor and use that id in advice to determine whether it was the correct instance for that advice. In the case of widgets with behaviour (e.g. "execute foo() when this button is pushed", the behaviour is attached to the widget once, right after construction of the widget. In cases where the widget has state that needs to be maintained, a pointer to the widget can be grabbed once, right after construction of the widget.

Status

References

[Vasseur2004] Alex Vasseur, Load-time weaving with AspectJ 1.2, The Aspect Blog, May 29, 2004, http://www.aspectprogrammer.org/blogs/adrian/2004/05/loadtime_weavin.html.

[Xerox200?] Xerox Corporation, Special cases, The AspectJ Development Environment Guide, Chapter 5, http://www.eclipse.org/aspectj/doc/released/devguide/ltw-specialcases.html, downloaded 12 Mar 2006.