Layout has always been a major weak point of the Swing toolkit. At the API level, Swing supports virtually any layout you can imagine, but in practice, the default layout managers leave much to be desired. Over the years, enterprising developers have created a variety of utility classes to make the job easier, but recent work on the problem suggests that the best way to lay out a Swing GUI is to remove layout from the Java code altogether, either through a visual builder like Matisse in NetBeans 5.0 or by using a language other than Java to specify the GUI. One common solution is to use XML that completely separates GUI construction from program logic. This article will introduce an open source library, SwiXml, and show you how to construct your Swing user interfaces faster and more easily than ever before.
The Layout Problem
Building on its AWT foundations, Swing has very powerful support for creating complicated UI designs. Using a standard layout manager like GridBagLayout or SpringLayout, a developer can build an attractive interface that automatically accounts for different platform component sizes, fonts, and languages. You can even create your own custom layout manager for tricky cases like maintaining a fixed ratio. With the right layout manager, you can do almost anything.
In practice however, as the humorous animation "Totally Gridbag" shows, Swing layout can be a pain to use. GridBagLayout code is typically verbose and annoying to read after the fact. SpringLayout was intended for visual GUI builders, so coding it by hand is extremely difficult. Over time, layout code often becomes unwieldy, resulting in ugly UIs that break on different platforms. This is the opposite of progress. There has to be a better way.
In recent years, many developers have decided that it is a good practice to separate the GUI layout from event handling and program logic. This keeps the program logic cleaner and allows the layout to be maintained separately, often by a different developer. Some have gone a step further to specify layout in a language other than Java. These days, the natural choice for any new language is of course XML, and a quick internet search for "java xml gui layout" will return many commercial and open source layout products. One of the best is SwiXml, a tiny but powerful library that transforms simple XML descriptions into attractive user interfaces.
What Is SwiXml?
SwiXml is a small Java library created by Wolf Paulus in 2003 to produce Swing GUIs from a small XML language. SwiXml doesn't introduce any new layout managers or component classes. Instead, it directly operates on the Swing classes using reflection. This means that the XML syntax is easy to learn for anyone used to the Swing API. It also has the side benefit of keeping the library very small (under 60k, plus the JDOM .jar), which makes application deployment a pleasant experience.
A Simple Example
Before I get deeper into the syntax and mechanics of SwiXml, I'd like to show you a short example to get a feel for how it works.
This is a very simple XML file that will create a frame with one text field and a button:
There is one frame element with two sub-elements for the two components. The elements have many more optional attributes, but these are the basics necessary to show something on screen.
Next, you need a static main method for your application.
HelloWorld.java
import java.awt.event.*;
import javax.swing.*;
import org.swixml.*;
public class HelloWorld {
public JButton quit;
public HelloWorld() throws Exception {
new SwingEngine(this).render("HelloWorld.xml")
.setVisible(true);
quit.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent evt) {
System.exit(0);
}
});
}
public static void main(String [] args) throws Exception {
new HelloWorld();
}
}
This class looks just like a normal Swing application. The only unusual thing is the following line:
new SwingEngine(this).render("HelloWorld.xml").setVisible(true);
This is what calls the SwiXml API to parse the HelloWorld.xml file and makes the resulting frame visible on screen.
To compile and run the application code, you need to have the SwiXml and JDOM .jars in your classpath:
Running the program above will give you an application that looks like Figure 1:
Figure 1. HelloWorld using SwiXml
There is a lot of magic involved here, so I will go through it step by step. The SwingEngine class is a parser that reads and processes the XML file. It takes each element in the XML and converts it into a Swing component, placing them directly in the hierarchy. This is all pretty straightforward. The quit button is the tricky part. The button is declared as a field in the HelloWorld class, but the object is never directly created or assigned, and yet the addActionListener method doesn't throw a NullPointerException. How can this happen?
If you look at the XML file closely, you will see the button element has an attribute called id with a value of quit. At run time, the SwingEngine will create the button object during the parsing phase and then assign it to the quit field using reflection. This means the quit field will no longer be null by the time the action listener is added. In order to perform this sleight of hand, the SwingEngine needs a reference to the class with the fields, in this case HelloWorld. That is why I passed this into the SwingEngine constructor. It is this reflection trick that makes SwiXml so powerful. With a reference to your main class, SwingEngine can build any user interface and attach it directly to your fields, saving you lots of boilerplate code.
The reflection-based system also has the benefit of keeping your GUI layout separate from your event-handling logic, making maintenance a lot easier in the long run. Note that you may need to make your GUI component fields public so that SwiXml can access them. Recent versions of SwiXml can access any field, public, protected, or private; using reflection, however, accessing private fields may cause a security violation in sandbox environments like applets or unsigned Java Web Start applications.
SwiXml can handle pretty much every Swing component, including menus, tables, and even inner frames. It uses a simple naming system (usually just dropping the leading "J") so if you already know Swing, it will be easy to learn. All of the standard layouts are supported, as well, though using the GridBagLayout from XML can be cumbersome (just as it is in code form). Let's take a look at another example that uses more complicated layout and some nested components.
This XML file is launched from code that looks like this:
EmailTest.java
import org.swixml.*;
import javax.swing.*;
import java.awt.event.*;
public class EmailTest {
public JMenuItem quit;
public EmailTest() throws Exception {
new SwingEngine(this).render("EmailTest.xml")
.setVisible(true);
quit.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent evt) {
System.exit(0);
}
});
}
public static void main(String[] args) throws Exception {
new EmailTest();
}
}
The finished layout looks like Figure 2:
Figure 2. Email layout using SwiXml
SwiXml and Actions
In addition to components, SwiXml has direct support for Actions. You can bind a button, menu item, or any other Action-aware component directly to an Action field in your main class. It also lets you set Action properties like mnemonics, accelerators, and tooltips directly from your XML file. These features let you remove more code from your classes, resulting in a cleaner application design and more maintainable programs.
Here is a simple example showing an Action shared between two components.
ActionTest.java
import java.awt.event.*;
import javax.swing.*;
import org.swixml.*;
public class ActionTest {
// Create an Action as a member variable
public Action quit = new AbstractAction() {
public void actionPerformed(ActionEvent evt) {
System.exit(0);
}
};
public ActionTest() throws Exception {
// set the Action's name
quit.putValue(Action.NAME, "Quit");
// build the GUI
new SwingEngine(this).render("ActionTest.xml")
.setVisible(true);
}
public static void main(String[] args) throws Exception {
new ActionTest();
}
}
The code above creates an Action member variable called quit. Notice that the ActionTest constructor sets the NAME property of the action to "Quit"before building the GUI from XML. This ensures that any components which use the action will start with the same NAME property. If the property was set after building the GUI, then any customizations done by the XML would be overridden by the putValue() call, which may not be the desired behavior.
The XML file above creates a frame with one button and one menu item. The two components share the same action by using action attributes that point to the same named action: quit. The menuitem has a second attribute, accelerator, which overrides the current accelerator property of the action, if any. The button element has extra attributes to set the text and tooltip text for the button. These settings will override the defaults in the action, allowing you to customize values for each component. If the properties are later set on the action using putValue(), then the new value would override any values set here in the XML. By combining actions and the XML settings in different ways, you can create the appropriate behavior for your application.
Using XInclude
As your interface grows, you may want to split the UI definition into multiple files. SwiXml supports this in two ways. First, you can use multiple files and load them independently. For example, you could create one file for your main application screen, one for the help system, and one for the preferences dialog. Any SwiXml file can be resolved into an instance of Component, so you can structure your files to build frames, panels, or even a single text field, each loaded with a call to SwingEngine.render().
SwiXml also supports the XInclude syntax, letting you split your XML into several files that are bound into one master file and loaded as a single unit. This can be used to separate sub-panels and menus into other files without effecting the Java code at all. Here is a simple example that has a main XML file (XITMain.xml) containing the main GUI and a secondary file (XITSub.xml) containing a sub-panel.
XITMain.xml
<frame size="320,150" title="XInclude Test">
<menubar>
<menu text="File">
<menuitem text="Open"/>
<menuitem text="Save"/>
<menuitem text="Close"/>
<menuitem text="Quit"/>
</menu>
</menubar>
<panel constraints="BorderLayout.CENTER">
<button text="Button in the main file."/>
</panel>
<panel constraints="BorderLayout.SOUTH"
include="XITSub.xml#subpanel"/>
</frame>
XITSub.xml
<doc>
<panel id="subpanel" layout="BorderLayout">
<button text="Button in an included file."/>
</panel>
</doc>
XIncludeTest.java
import java.awt.event.*;
import javax.swing.*;
import org.swixml.*;
public class XIncludeTest {
public XIncludeTest() throws Exception {
new SwingEngine(this).render("XITMain.xml")
.setVisible(true);
}
public static void main(String[] args) throws Exception {
new XIncludeTest();
}
}
In the code above, the SwingEngine will combine the XITMain.xml and the XITSub.xml files at run time. The Java code doesn't even know that there are two files involved. It sees a unified component tree and can interact with it as normal. This transparent ability to merge multiple files gives the developer a powerful organizing tool that doesn't clutter up the Swing code at all.
Custom Components
If there isn't a standard Swing class that does what you want, you are always free to build a custom component. SwiXml can support your custom component through a feature called custom tags. These let you define new tags that map to your components. For example, suppose I have a custom JButton subclass that I use over and over in a drawing program:
ColorButton.java
import java.awt.*;
import javax.swing.*;
public class ColorButton extends JButton {
public void paintComponent(Graphics g) {
g.setColor(getForeground());
g.fillRect(0,0,getWidth(),getHeight());
g.setColor(Color.black);
g.drawRect(0,0,getWidth()-1,getHeight()-1);
}
}
I can define a custom XML element called <colorbutton> by registering it in the SwingEngine's tag library like this:
CustomComponentTest.java
import org.swixml.*;
import javax.swing.*;
import java.awt.event.*;
public class CustomComponentTest {
public CustomComponentTest() throws Exception {
SwingEngine eng = new SwingEngine(this);
eng.getTaglib().registerTag("colorbutton",ColorButton.class);
eng.render("CustomComponentTest.xml").setVisible(true);
}
public static void main(String[] args) throws Exception {
new CustomComponentTest();
}
}
Once the class is registered I can use it in my XML just like any other Swing component:
Once compiled, the finished program would look like Figure 3:
Figure 3. A Custom Component using SwiXml
Conclusion
SwiXml has many features beyond what I have discussed here; these include direct support for resource bundles, making it very easy to localize your application. There are also built-in extensions for Mac OS X, like automatically using the single menu bar and binding actions to the Application menu.
SwiXml is a powerful GUI layout tool, and most importantly, layout is the only thing it does. It doesn't have features to specify event code, animations, or anything else. This means it is easy to learn and small enough to use pretty much anywhere you can use Swing, even in downloaded Java Web Start applications or applets.
Best of all, SwiXml is free and released under an Apache license. This author once created his own similar layout binding system and has now switched entirely to SwiXml because it does the job very well with little extra effort. The net result of working with SwiXml is delivering better-looking applications in less time, and that is always a good thing.
Comming form MAC OSX and Cocoa nib files. I am surprised after more than 10 years of life, all java has to offer on the desktop is yet another way to create a "Simple UI".
How will this technology scale when you are trying to do a rich user interface with many controllers and custom views and pixel precise alignment.
Without an editor like InterfaceBuilder all one is left to do is "Simple UI" that can't simply compete.
Oh and what's up with the layouts? Can we have a real dynamic layout ?
Common guys 10 plus years to copy Interface Builder in java is that too much work ?
I reviewed SwiXML after a colleague of mine pushed for it two years ago. After reviewing the toolkit, it was clear that it is far too restrictive, despite its neat ideas:
1. limited to Swing only, and yet many configurations in Swing requires things beyond swing, like list, vector, object array, etc. As the result, one has to deal with heavy mixing of XML and Java code, which actually makes it more problematic than pure Java alone. If you take a look at SwiXML sample codes #9 ComboBox, that alone defeats the purpose of Localization efforts of SwiXML since you can't specify in XML the items in combobox to be shown.
2. Layout. Believe it or not, GridbagLayout is as frequently used as BorderLayout if not more. Some complex layouts simply have to be done in GridBagLayout. 2 years ago, its support simply wasn't there. The EmailTest in this tutorial is actually a bad one because it makes an assumption that the height of a JTextField is the same as a JLabel, which is clearly not the case. If you look at the picture, you will notice the shifting of the "Subject:" label. Fortunately SwiXML has GridBagLayout now. However, the way specifying in SwiXML layout is very counter intuitive. I will elaborate on this point later.
Due to these and other project specific reasons, I stayed with coding Java GUI by hand for a while until I wrote my own XML->Swing toolkit. While it is important to separate GUI and business logic, it can be done in the Java only too. Also, it is far more important not to break existing codes before fully switching to XUL.
Below is a shameless advertisement for my own toolkit :)
Despite the fact that I disliked SwiXML, the idea of XML->GUI SwiXML indeed has advantages. I had my own script engine (not in XML, but in a language I created called CookScript) that did basic menu/toolbar configuration that satisfied my own requirements. Some complex layouts do get tedious in Java to switch from one to another, since I normally try different GUI layouts and see which one looks better. So after weeks of planning, I wrote the first version of CookSwing from scratch in 3 days (just to give you an idea how easy it is to write a XUL on your own).
If you had tried CookSwing, you would immediately recognize the significant difference between CookSwing and SwiXML in dealing with layout constraints.
Sure, CookSwing is a bit more verbose, but constraint is NOT a property of the Hello button. Also in SwiXML, the constraints attribute can be easily burried into the long property list of a particular child component.
In this case, SwiXML's layout constraint location is confusing. Imagine that the button is actually another panel that has another layout, it can be even more difficult to understand. CookSwing's layout constraint is upfront visible on how it a component is added, and nesting several jpanels poses no difficulty in understanding the layout.
As mentioned before, limiting XUL to Swing only wouldn't work, due to many things that need to be addressed. In CookSwing, you can specify things in JComboBox directly:
<list>
<string text="1st item"/>
<string text="2nd item"/>
<string text="3rd item"/>
<!-- selecting the first and 2nd item -->
<array type="int" setas="selectedindices">
<int value="0"/>
<int value="1"/>
</array>
</list>
Enough bashing of SwiXML :) CookSwing was certainly built on top of SwiXML's idea and simply refined some points. The implementations are of course completely different as I disagree with SwiXML's philosphy of Swing only. Using only reflection seriously tied the hands of developer using SwiXML.
You can check out CookXml at http://cookxml.sourceforge.net/ and CookSwing at http://cookxml.sourceforge.net/cookswing/ .
Thumbs up for SxiXml
2006-03-07 22:28:23 jelliffe_rick
[Reply | View]
Nice to see some promotion for SwiXml. I have been using it for a few years now: rock stable, saves lots of programer time, much smaller than GUI-generator-generated code, more bang per line on screen makes for easier editing, use of Swing means no need to learn different concepts, can be extended with custom components: no downside that we have found at all, actually!
We do tend to keep major components as separate SwiXml components: so the menu bar is one SwiXml component and the button bar is a different one.
We use a naming trick for menus and buttons: each major subsystem has its own prefix, and a generic action listener dispatches the actions to each subsystem to be taken care of.
At one stage in programming history, one central method of developing systems was to first design optimal little languages to express each part. (This was particularly true in the LISP and UNIX worlds.) It became inefficient compared compared to components and OOP, largely because of the inefficiency of developing multiple syntaxes (and programmers lost the skill of working with multiple syntaxes.) XML allows the benefits of the little language approach again without the mental overhead of learning multiple syntaxes. (Contrast this with LISP: people compare XML and LISP as if it were about <> versus () when in fact in LISP you very often made your own syntax...fixed syntax versus homemade becomes the issue not () versus <>.)
SwiXml is also a great advertisement for the usefulness of reflection, btw!
I'm a little freaked out right now. I had this SAME idea on the way to work today because I was frustrated with writing java UI code. I come home to a link in my instant messenger window to this page @_@. I'm not surprised that someone already had the idea... just a little weirded out how things worked out.
Anyways, have you thought about writing a "compiler" that would instantiate the GUI (basically a call to SwingEngine.render()) and then serialize the UI to a file so you don't have to parse the XML file and do all the reflection "magic" every time the app is run? Loading the UI from a file isn't faster than building the UI from java code, but it might be faster than parsing the XML file and then building.
One concern I'd have is how well this works in terms of platform independence. For example, will it work well with a Mac Menubar vs the Linux/Windows style of Application Menubar? As I recall, this has to be handled in the code somewhere.
Similarly, how does it work with dialogs? For example, I believe one has to use AWT for native file dialogs and this UI system is based on Swing only, right?
SwiXml is just a layer on top of Swing so you can do anything you can do with Swing, and you are limited by Swing's limitations. For Mac support you still need to set up the correct code to use a single menu bar and register your event handlers with the about, preferences, and quit menus.
For dialogs everything is the same as Swing. Swing has many dialogs but if you want to use the native file dialog you will have to use java.awt.FileDialog. Since this dialog isn't customizable, however, it doesn't matter whether you are using SwiXml or standard Swing code to call it.
don't fear layoutmanagers ;-)
2006-02-24 05:52:52 gernot
[Reply | View]
I'm working on swing projects now for years and I agree, coding UI by hand is somewhat annoying as you don't see on the fly what you're currently doing. Also layout manager support is not as good as it could be and the documentation of GridBagLayout is weak. But if you got it, you can do almost everthing with it. IMHO a powerfull GUI design tool is needed. (I didn't test Matisse yet) .
I don't see any benefit in using XML. You must know XML AND Swing (or whatever GUI API), it's very unintuitive to handle, no sophisticated error handling in XML if something went wrong. The only reason to describe GUIs with XML is if you want to have some generic description that you want to convert to Swing, AWT, HTML...
don't fear layoutmanagers ;-)
2006-03-03 11:28:00 mimix
[Reply | View]
The greatest feature of SwixML is that, if you get it right, you can change the layout on the fly indeed.
This is how we do it here, we have a framework to render the XMLs, usually representing panels embedded in a "parent XML" (the JFrame), and we can change the interface looks without restarting the application, it justs gets rendered every time a button is clicked, for instance. Besides that, swixml with form layout patch (found on the Swixml community list), even our webdesigner can manage to create the screens.
The idea of an XML file is much better than coding any layout. I used to program delphi, and i still believe it is sin to code any simple layout in swing. Java as a language may be 100 steps ahead of delphi, but swing as GUI library is 1000 steps behind delphi version 1! Even if one feels some strange obligation to code layout, why not based it on single layout concept which stays the same across all components? For example, use anchors, bands, etc. Why did sun not have a look at products such as VB, delphi, or even ILOG Views (a C++ GUI library)?
This ADDS complexity
2006-02-23 07:01:03 davetron5000
[Reply | View]
So, it doesn't save you from the complexity of the LayoutManagers (which, with some moderate experience, are not THAT complex).
It requires an external file that is not checked at compile time
It requires you to learn not only the methods and interface of the Java classes for the Swing components, but the XML attributes of the same. Now I have to know TWO APIs when reading code.
The code to implement the examples would be far simpler than the XML crud required by this tool. I can't believe anyone would PREFER to have their code spread out all over the place. What is the obsession with removing things from code. are .java files in such short supply that we must remove as many things from them as possible? Is the step of compiling so hallowed and precious that it must not be done unless absolutely necessary?
Why don't we have support form IDES and a JSR yet?
2006-02-22 18:24:30 flozano
[Reply | View]
XML dialects for user interface (specially for Swing user intefaces) are not new. And it's not fair to compare them to Web MVC frameworks. Those frameworks add a lot of code by themselves and ease a web developer life, while XML GUI dialects for Swing just add a different syntax for working with Swing components and layours. You won't write less code, you won't have new features (like Struts declarative validators) , you get just a more manageable code that does the same things the same way.
What I cant't underst is why Java has yet so poor support for those. He have years of experience with Gnome, whete libglade XML are the preferred ways to develop GUIs, with support from the official GUI builder, Glade.
a Swing XML dialect is so simple that there's no reason there shouldn't be a standard dialect defined by a JSR and the run-time support as part of standard JavaSE. And this standard should be the prefered way to work with visual GUI builders from any IDE.
The lack of those (standard XML dialect, implemented as part of Java SE and supported by all major IDEs) is a sad sign that sometimes the JCP donesn't serve the Java user and developer community interests, but the tool vendor interest. They have nothing to gains from that kind of standard, which would make it easy to migrate from an IDE to another.
Why don't we have support form IDES and a JSR yet?
2006-02-23 03:46:50 murphee
[Reply | View]
Sun tried to do something like that in Java 1.1. with Beans and Serialization. In 1.1, there was a the BDK which shipped with a tool that allowed you to drag live GUI Beans, arrange them and hook them up with Events. I think the basic idea was to build these, then freeze them (ie. serialization) and when you want to use it, simply thaw it (unserialize) and show it on the screen.
Seems like there's some spawn of that still living
https://bean-builder.dev.java.net/
I think this idea stems from NeXT and NextStep and their interface builder (maybe someone has more info on that).
The reason why this isn't available today is that JavaBeans achieved pretty much none of their goals and are now mostly just responsible for get/set/is and add/remove/set naming standards.
Why don't we have support form IDES and a JSR yet?
2006-02-24 21:02:17 flozano
[Reply | View]
Today with XML serializaton and XML Binding as part of Java SE, it would be much easier than in 1.1 times. Yet no word on that from the JCP :-(
While Sun / JCP hangs, JavaGnome guys provide integration with Gnome Glade and native look and performance for Linux users (actually for Gtk / Gnome users whatever the platform)
Adding to that the swing troubles with international keyboards, font rendering, and cut-and-paste, JavaGnome becomes a very interesting alternative if you target Linux and Unix desktops
See JSR-273: Design-Time API for JavaBeans (JBDT) on Java.net
or the JCP.
Layout isn't that hard
2006-02-22 06:13:56 carmello
[Reply | View]
Layout isn't that hard in my opinion. I have got a few years of experience during my school. I use flowlayout, borderlayout and tablelayout (not part of jdK) and always do it by hand, no problem.
How is this different?
2006-02-22 04:12:29 murphee
[Reply | View]
How is SwiXmL different from all the tens of other XML based GUI markup languages in Javaland?
Here's a list:
http://java-source.net/open-source/xml-user-interface-toolkits
The situation with these things is just as bad as with Java Webframeworks... new ones keep popping up right and left, but none brings any interesting features.
With SwiXml, I don't see any benefit, actually I think it's even worse off than some others, as it seems very specific to Swing (hence the name?) and I don't see anything interesting done with the layout.
As for GUI designers (the person, not the tool) working with the XML language is better than some GUI builder (the tool) for prototyping and polishing the design?
Sure... except that the designer has to learn the XML dialect and semantics of this particular language... then stumble over some problems, then search for non-existant documentation (many of these toolkits are half dead or badly documented), etc etc, and finally ends up spending
twice as much time fiddling with this than she would have handcoding the GUI, blindfolded with one hand tied behind their back...
I'm all for making GUI building easier, and decoupling logic from view is good practice... but XML GUI definition languages just add a problem, and don't offer a solution... yet?
How is this different?
2006-02-23 06:09:17 seanmont
[Reply | View]
That list missed Buoy (buoy.sourceforge.net), which is built on Swing, though a lot of folks list it as a Swing alternative. I'm sure there are others.
I'd be curious to see how much "market share" each of these XML UI toolkits has... any guesses?
How is this different?
2006-02-22 09:07:22 joshy
[Reply | View]
You are correct that there are many XML based GUI markup languages out there. Clearly it's an idea that people like. It's just that none have gained huge mindshare yet. I recall the state of web frameworks being like this about five years ago. Now there are a smaller number of well supported frameworks that handle 95% of what developers need. I think the same will happen with XML markup languages.
I chose SwiXml out of the many available specifically because it is Swing specific. It is a good choice for people developing pure Swing apps and who are already familar with Swing (meaning you don't have to learn too much new). It's also very lightweight and easy to integrate with existing Swing applications. If you were starting a brand new application from scratch I might recommend you look at Matisse instead.
Of course the beauty of the Java ecosystem is that we have lots of options so we can choose what is best for our needs.
How is this different?
2006-02-22 13:49:41 murphee
[Reply | View]
I don't think it's a matter of mindshare; that kind of markup has been around for decades (the oldest example I can think of are Dialog specifications in resources for Windows/OS2 applications, although I'm sure there were uses before that).
One problem is the rift between definition language and programming language. Not to mention that it's not really convenient to dynamically build GUIs at runtime (from some data).
If you have access to a current version of Mathematica, take a peek at GUIKit:
http://www.wolfram.com/solutions/guikit/
It also uses Swing, but as Mathematica is a functional language that makes use of s-exprs easy, you don't need XML.
Believe me, it'll look similar when you look at sample code, but once you use it... it's a different world.
This is a direction that these markup languages should go into, but can't, due to Java inflexible syntax.
like your article very much, but I think the intro is a bit misleading. You talk about how complex layout managers are to use (and yes, they are) and then introduce SwiXML.
But all your examples use a BorderLayout, so it seems that SwiXML doesn't add a solution to the core problem.
Or are there smarted layout managers available in SwiXML?
SwiXml lets you move the layout out of your code. That is it's core feature. It doesn't simplify the layout task itself (since you are still using Swing layout managers) but it makes it easier to manage. This is especially important for large programs where the user interface is spread out among multiple developers and multiple months (or years, in some cases). I think SwiXml makes the overall job of dealing with layout a lot easier.
That said, Wolf Paulus, the author, told me he plans to work on support for the JGoodies Form Layout next, which I have found does make layout itself a lot easier.
- Josh
Nice and Simple!
2006-02-21 07:31:12 lucasjordan
[Reply | View]
I like this method of GUI design, I think I implemented something like at some point :)
I think the idea of specifying actions and having them wired up automatically is the best pattern for something like this. However I wish there was a way to do so without passing in an object where each action is specified as a field. It would be more dynamic if you could say something like:
new SwingEngine(listOfActions).render("HelloWorld.xml");
or even
new SwingEngine(Map idsToComponents, Map actionNameToAction)
Joshua keep up the good posts!
-Lucas
Nice and Simple!
2006-03-23 18:15:23 jkoenin
[Reply | View]
Take a look at SwiXAT which builds on top of SwiXML.
http://www.swixat.org
All of these systems have positives and negatives when compared to each other, Java code, and others, but I've found SwiXAT to be one of the least cumbersome GUI frameworks I've used over the years. Granted, it has some issues, but it's a fairly young project.
Nice and Simple!
2006-02-23 01:18:20 frankmeissner
[Reply | View]
Lucas,
my preffered usage of actions in swixml (I'm one with write access to the cvs) is to have initclass attributes for my "main" buttons, menu items and the like. I only use the action field approach for dialogs with several actions belonging together ("Ok", "Apply", "Cancel", "Add Item", "Edit Item", ...)
The main actions are usually larger (30 productive lines up), so it is IMHO better to have them as separete classes...
But the idea with the map is excellent and not that hard to accomplish...
Frank Meissner
Nice and Simple!
2006-02-22 09:13:12 joshy
[Reply | View]
That's an interesting idea. I'd email the project lead and suggest it.