Using Aspects to build GUIs

DuckySebastian539Final Sukesh Chopra, Kaitlin Duck Sherwood, and Sebastian Streg

Using traditional Object-Oriented programming techniques, code for building a GUI becomes tangled: layout code becomes tangled with behavior code. For example, consider a simple GUI with one button and one label, shown below, where the the label displays the number of times that the button has been pushed. When creating the label, the developer has to specify not only the visual aspects of the label, but also keep a pointer to the label that the button can use. When creating the button, the developer has to specify not only the visual aspects, but also define the behavior that the button should take when it is pushed.

public class Main {
   JFrame mainFrame;
   JPanel mainPanel;
   JLabel countLabel;
   public JButton countButton;
   int pressCount;

   
   public Main() {
      //Create and set up the window.
      mainFrame = new JFrame("Sample");
   
      //Create and set up the panel.
      mainPanel = new JPanel(new GridLayout(2, 2));
      
      //Add the widgets.
      countLabel = new JLabel("0", SwingConstants.LEFT);
      countButton = new JButton("Count");
      
      //Add the widgets to the container.
      mainPanel.add(countLabel);
      mainPanel.add(countButton);

      // BEHAVIOR
      pressCount = 0;        
      countButton.addActionListener(new ActionListener() {
         public void actionPerformed(ActionEvent e) {
            pressCount++;
            countLabel.setText(""+ pressCount);
         }
      });

      //Add the panel to the window.
      mainFrame.getContentPane().add(mainPanel, BorderLayout.CENTER);
            
      //Display the window.
      mainFrame.pack();
      mainFrame.setVisible(true);
   }

While the visual aspects of the GUI can easily be generated with XML or a GUI builder, the behaviour aspects cannot. Because the behavioural aspects must be embedded in the class that lays out the GUI, it is difficult to use automatically generate the layout code: re-generating it would stomp on the behavioural code.

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 had two decisions to make about tools: what language to use and what tools to aid us in translating from XML to GUI.

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) is, beside Luxor, one of the most used XML to GUI Tools, and is built on Java Swing. It has its own XML dialect whose numerous pre-defined tags and attributes can be used intuitively for experienced Swing Developers. The XML files are translated at run-time. Furthermore it provides also a useful documentation how to use tags and attributes for inexperienced Swing Developers.
• Thinlet seemed very similar to Swix, but not as good.
• gui4j was limited in number of attributes for objects is limited.

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

Out of the box, Swix takes two input files: an XML file which describes the GUI, and a Java class that does some initialization, defines actions used by the GUI (as methods in the class, not in the widgets' class) , and starts Swix.

Approaches considered

There were two main issues we needed find solutions for.

• 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

We attempted weave the Swing widgets at load time. We spent a huge amount of time trying to configure the tools, with no success. The documentation that exists for AspectJ with Java 5 is not entirely helpful. The official docs are reference materials and seem to be aimed at people who already understand the material. We found very few sites with tutorials and/or example code, and the best load-time weaving example[Vasseur2004] that we found was out of date.

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

We considered several solutions for 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. JButtonButtonOne and JButtonButtonTwo to 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 theorized 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.

Unfortunately, modifying Swix to allow inserting the instance ID to the constructor is very complicated. Instead, immediately after object creation, we pass the ID to a dummy method: dummyParserMethod(obj, object_id); We then key advice on the dummyParserMethod:

  after(Object obj, String id): call(* Parser.dummyParserMethod(Object, String)) && args(obj, id)

  {  

     if(id == "FlowLayout1")

     {

        XButton xbutton = (XButton)obj;

        xbutton.addActionListener(new ActionListener() {

           public void actionPerformed(ActionEvent e)

           {

              // TODO: add in behaviour for FlowLayout1 here

              System.out.println("Behaviour for FlowLayout1 not yet implemented.\n");

           }

        });

     }    

  }

Skeleton generation

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. The auxilliary Java class is now much simpler: it has only one string that ever changes, so it can be made automatically.

Broadly speaking, there are two important characteristics of widgets: actions (e.g. button pushes) and state (e.g. text fields, labels). Actions can be attached to widgets once, in advice after() the widget is created. Widgets with state need to have a pointer to them kept in the aspect so that they can be used by advice.

Status

We lost a huge amount of time trying to configure Eclipse to get load time weaving to work, so are a bit behind. (We are not the only group bitten by configuration issues; Arjun also spent a lot of time configuring Eclipse.)

We have modified Swix so that instead of creating JComponent instances, it creates instances of our wrapper classes. At this point, it makes XButton, XTextField, XPanel, and XLabel instances instead of JButton, JTextField, JPanel, and JLabel instances.

We have written XSLT that translates the XML (including the actions) into an aspect file. We also create the starter Java file -- it is trivial to create. The Swix input XML format already had a slot to define an id; we currently make that mandatory. We hope to remove that restriction in the future.

At this point, we have a two-step process: we create the aspect and the auxilliary Java class statically and then start Swix using those files as input; we do not expect significant problems combining those steps.

At this point, we have not demonstrated that the advice and Parser code work well together. There is some configuration bug that is preventing even the simplest of pointcuts/advice from being recognized. Even this will not fire:

public aspect SwixAspect
{
  after(): call(* SwixClass.moo(int))
  {
          System.out.println(".....................................................");
  }
}

We feel reasonably certain that we will be able to figure out the configuration issue (or get help on it), just not tonight.

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.