Difference: DuckySebastianSukesh539dProjectUpdate (4 vs. 5)

Revision 52006-03-26 - TWikiGuest

Line: 1 to 1

META TOPICPARENT	name="DuckySebastianSukesh539Project"

Using Aspects to build GUIs

Sukesh Chopra, Kaitlin Duck Sherwood, and Sebastian Streg

Line: 78 to 78

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

Added:

>
>

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.

Line: 137 to 139

This structure is so regular that a skeleton can be generated automatically.

Added:

>
>

Note that we can take advantage of being able to define identical pointcuts to separate advice for different buttons. We could have made one advice with if statements to figure out which instance it was, but that would jumble different instances' actions together.

In the case of widgets with behaviour, 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.

Added:

>
>

Unmodified, Swix takes as inputs

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

Line: 148 to 153

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.)

Changed:

<
<

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.

>
>

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, and XLabel instances instead of JButton, JTextField, and JLabel instances.

We have extended the format of the Swix input XML format slightly. It already had a slot to define which action should be used for a widget (although the code for those actions needed to be placed in the auxilliary Java class); we now recognize a tag in the XML which contains code for actions. We have written code that translates the XML (including the actions) into an aspect file.

The auxilliary Java class is now much simpler: it has only one string that ever changes. We currently make that file completely automatically.

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.

@@@ we probably need to hack out the bits where the action is called -- it will try to go to the aux Java class. @@@ do we need to ignore the tags?

View topic | History: r8 < r7 < r6 < r5 | More topic actions...