Biased comment :)
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.
In SwiXML, a BorderLayout panel looks like:
<panel layout="borderlayout">
<button Text="Hello" Action="submit" constraints="BorderLayout.CENTER"/>
</panel>
and in CookSwing:
<panel>
<borderlayout>
<constraint location="Center">
<button Text="Hello" actionlistener="submit"/>
</constraint>
</borderlayout>
</panel>
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 GridBagLayout SwiXML has now,
<panel layout="GridBagLayout">
<button text="Wonderful">
<gridbagconstraints id="gbc_1" insets="2,2,2,2" gridx="0" gridy="0" ipadx="15" ipady="15" weightx="1" weighty="1"/>
</button>
</panel>
and in CookSwing:
<panel>
<gridbaglayout>
<gridbaglayoutconstraints insets="2,2,2,2" gridx="0" gridy="0" ipadx="15" ipady="15" weightx="1" weighty="1">
<button text="Wonderful"/>
</gridbagconstraints>
</gridbaglayout>
</panel>
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:
<combobox>
<string text="1st item"/>
<string text="2nd item"/>
<string text="3rd item"/>
</comboxbox>
Or another example with JList:
<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/ . |
java.net RSS Feeds
