XUL4J - XUL for Java

by Ronald Koster, version 1.0, 2002-12-16


XUL from Mozilla.org is a great tool to build GUIs with. However, its main focus is building in JavaScript, not Java. XUL4J is a not (yet) existing library offering a Java implementation of XUL.

NB. For an alternative to XUL see SwingML.

Design Goals for XUL4J

The following design goals have been identified for XUL4J:

Goal 1. The Layout of an application's GUI can be definied fully in XUL, ie. using XUL files only. No need for any Java coding for defining the layout of the windows and all their widgets.

Goal 2. No XBL. The binding of actions to the control widgets is done via the 'id' attribute of the XUL widgets. The actions themselves are coded in Java and they are the only Java coding to be done for an application to build. A control widget is a widget which can have an 'oncommand' attribute. For control widgets the 'id' attribute is mandatory, for non-control widgets it is optional.
NB. Goal 1 and 2 ensure one can build a fully functional GUI including the bindings with the application logic, without having to subclass any of XUL4J's widget classes. Thus no knowledge of XUL4J is required to build a GUI application.

Goal 3. XUL4J encapsulates all Java Swing classes. When a developer whishes to manipulate GUI components in his Java code he can do so by manipulating XUL4J classes only. No direct access to any Java Swing class is required, ie. only XUL4J classes will have to be imported, not a single Java Swing class.
NB. Goal 1 ensures the need for accessing GUI components in the Java code directly will be rare.

Goal 4. XUL4J requires only a XML parser library of free choice. No need for other libraries. This makes using the XUL4J jar easy to use an light weigthed. When for example using Xerces from Apache.org as an XML library, one will have to include in the class path only the following jars: xerces.jar;xul4j.jar.

For for more on these design goals see the XUL4J package documentation.

Improvements to XUL

XUL now prescribes every XUL file must have the <window> element as the root element.This hinders reusage of code. It would be beter to have:
  1. Root element of XUL files should always be the <xul> element. It has one mandatory attribute: 'version' holding the XUL version used in the file. The <xul> element can be the parent element of any XUL widget.
  2. All widgets have a new general attribute: 'href', holding a filename of a XUL file defining this widget. That is, the first occurence of a widget of the same type in that file is used. That definition is virtually inserted at the position of the widget with the 'href' attribute. The href widget inherits all attributes from the referenced one, but can still have its own attributes. Its own attribute override the inhertited ones. Most importend: overriding the 'id' attribute ensures other action code will be invoked for the href attribute then for the referenced one. Not overriding ensures the same code will be invoked.
For backward compatibility reasons XUL files with a <window> root element are still supported.

XUL4J should support this improvements.

Example, reusing a menubar and a button definition.

File 'btnOk.xul':

<!-- OK button. -->
<xul version="1.0">
	<button label="OK" id="90001">
File 'main.xul':
<!-- Applications main window. -->
<xul version="1.0">
	<window title="Main" id="10000">
		<menubar id="11000">
			<menu label="File" id="11100">
				<menupopup id="11101">
					<menuitem label="New" id="11111"/>
					<menuitem label="Open..." id="11112"/>
					<menuitem label="Close..." id="11113"/>
					<menuitem label="Close..." id="11121"/>
		<box id="12000">
			<button href="btnOk.xul"/>
File 'another.xul':
<!-- Another window of the application. -->
<xul version="1.0">
	<window title="Main" id="20000">
		<menubar href="main.xul" id="21000"/>
		<box id="22000">
			<button href="btnOk.xul" id="22502"/>

Project direcory

To do: build all XulWww classes mentioned in the package documetation.