Getting StartedBuilding Forms in XML
User interfaces are called 'forms' in XUI and these forms may be entirely defined using XML. In addition, the API includes a form designer as a download or an add-in form designer for NetBeans. The latter is still under development and can be unstable, but the XUI folks are very fast at turning around bug fixes (usually within a day or two). Your forms can be integrated into any Java modules, be they pages themselves or just pure application logic.
|Figure 2. The XUI Editor: The XUI IDE is pretty standard. |
Perhaps the best use for a framework like XUI is in the clean separation between the UI and the app logic, and in this article I'll show you how to do just that. The first thing to do is to download and unzip the release build of XuiALL. This contains the libraries and the UI editor IDE.
When you've unpacked the zip, you should see these files:
To launch the IDE, edit the start.bat
file to refer to your JDK installation; it should look something like this:
Note that Windows tends to choke on files called start.bat
, so it is also a good idea to rename this file. I called mine runEd.bat
. When you run this file, the IDE will launch (see Figure 2
The IDE gives you the facility to design a GUI in pretty much the standard way that every IDE doesby dragging and dropping controls, sizing them using the mouse, and customizing them using property editors. What the XUI editor brings to the table is that it takes your visual work and generates XML describing your UI on the fly. Listing 1
shows the XML for the simple tax form shown in Figure 2
You now have a nicely encapsulated description for your user interface, which is also easy to read (for a human) and fairly straightforward to parse. When you save out this form, it will be saved as the XML shown in Listing 1
. The next thing to do is to hook this UI up to your business logic to make it useful instead of just pretty. In traditional Java, your definitions of your UI would be in Java code and you would have a lot of work to create separate modules that interoperate between the UI and the functionality. From experience, it is almost always the case that the UI description and the functionality and business logic are mixed up within the Java classes.
|Figure 3. Handling the Action: Editing your XUI Java code-behinds.|
With XUI, separating them isn't just easy, it's automatic. Using the XUI editor, you select an item, associate the name of the event that processes that item, and XUI will create a separate Java class containing the stubs for running that event.
To try it out, download the sample
tax application for this article. Run it and click the Exit button. You'll see that the Action Handler for this button is called appExit
. Put the cursor in the ActionHandler
property field, over the appExit
text, and press Enter. You will be taken to the Java module containing the appExit
function (see Figure 3
This method has the code System.exit(0)
, which closes the current application.
Now, on to more interesting tasks: You want to write some business logic that interacts
with your display, but is still totally separate from it. In this case, you are going to calculate taxes, for which the formula is (0.2* ( Salary + Income – Deductions)), with the values of Salary, Income, and Deductions coming from the GUI. You'll then load the answer into the lTaxes
label. Thus you can see how the application interacts with the GUI for input to and output from your Java code.
This code is mapped to the Calculate button by setting its ActionHandler
property to doCalc
, which creates the function stub. Fill in this stub with the following:
public void doCalc()
XEdit tmpText = (XEdit) findComponent("tSal");
Double tSal = new Double(tmpText.getText());
tmpText = (XEdit) findComponent("tInc");
Double tInc = new Double(tmpText.getText());
tmpText = (XEdit) findComponent("tDed");
Double tDed = new Double(tmpText.getText());
Double dTaxes = new Double((tSal.doubleValue()
XLabel tmpLbl = (XLabel) findComponent("lTaxes");
What this code does is to create a reference (tmpText) to a control of type XEdit. An XEdit control is the basic text input control for XUI. It then searches for the control called tSal and when it finds it, it gets referred to as tmpText. The text is pulled out of tmpText using the getText()
method and is passed to the constructor for a new Double tSal (for salary).
This process is repeated for tInc (Income) and tDed (Deductions). The taxes are calculated by adding the Salary to the Income, subtracting the Deductions, and dividing the whole lot by five. This calculation is passed to the constructor of a new Double, containing the calculated Taxes.
The taxes are displayed on the Form using a label called lTaxes. This label is found, and cast to an object of type XLabel, called tmpLbl. The setText()
method is then used to amend it and the value of dTaxes is loaded into it.
|Figure 4. Doing your Taxes with XUI: Wouldn't it be nice to pay so little in taxes?|
So, you can see from this function, that even though the GUI logic is nowhere to be found, you can still interact with it in XUI by using findComponent
to get the appropriate controls. You can then associate the controls with a temporary object with which you can query or set the properties of the GUI controls. This is the principle of loosely coupled logic operating in a very useful manner!
While this simple example may not blow you away, consider how this can be used for something with high impact, such as the internationalization of a GUI. With this methodology, if you want to change the language of your GUI, simply change the XML defining ityour logic will have zero changes. If the control names stay the same, the program logic won't care!
You can see the finished sample application in action in Figure 4