Difference: DuckySebastianSukesh539dProjectUpdate (6 vs. 7)

Revision 72006-03-27 - TWikiGuest

  META TOPICPARENT 
 name="DuckySebastianSukesh539Project" 

 Using Aspects to build GUIs 
Sukesh Chopra, Kaitlin Duck Sherwood, and Sebastian Streg
- META TOPICPARENT
+ name="DuckySebastianSukesh539Project"
  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 as Swix) is beside Luxor one of the most used XML –>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. It separates in a clear fashion the description of the GUI elements (in a XML file) and the logic in form of the event-model (ordinary java code). 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.
->
>
+ 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 evaluation, we decided to use Swix as our XML translator.
->
>
+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.
 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.
->
>
+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:
-<
<
+public aspect AddListener {
  private XTextField countField;
  private XLabel pressCount;
->
>
+  after(Object obj, String id): call(* Parser.dummyParserMethod(Object, String)) && args(obj, id)
-<
<
+  after(String aName, String aLabel): execution(XButton.new(String, String)) && args(aName, aLabel)	
  {	  
	 if(aName == "buttonOne")
+	 {
-<
<
+		XButton xb = (XButton)(thisJoinPoint.getThis());		 
		xb.addActionListener(new ActionListener()
->
>
+	  if(id == "FlowLayout1")
+		{
->
>
+		  XButton xbutton = (XButton)obj;

		  xbutton.addActionListener(new ActionListener() {
 		  public void actionPerformed(ActionEvent e)
->
>
+		  {
-<
<
+			 button1 action;		 
		  });	  
		}
->
>
+				  // TODO: add in behaviour for FlowLayout1 here

				  System.out.println("Behaviour for FlowLayout1 not yet implemented.\n");
+	}
-<
<
+  after(String aName, String aLabel): execution(XButton.new(String, String)) && args(aName, aLabel)	
  {	  
	 if(aName == "buttonTwo") 
	 {		 
		XButton xb = (XButton)(thisJoinPoint.getThis());		 
		xb.addActionListener(new ActionListener() 
		{		 
		  public void actionPerformed(ActionEvent e) 
		  {			
			 button2 action;
 		  });
-<
<
+		}
->
>
 	}	

 }
-<
<
+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 state.

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

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.
->
>
+ 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.  We also have a pre-processing utility that creates a "skeleton" aspect that the users would flesh out with behavioural code.
->
>
+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, 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, XPanel, and XLabel instances instead of JButton, JTextField, JPanel, 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.
->
>
+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.
-<
<
+@@@ 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?
->
>
+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.

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