The two approaches aren't mutually exlusive. It seems to me that Swixml
is intended to be a simple, small, and lightweight Swing layout engine.
Good. As pointed out in this discourse before, JSR57 is not simple, at
depending upon your perspective is not small and lightweight.
Axualize seems to be nice in that it adds scripting to JSR57. That
scripting is provided through BeanScript, requiring Java knowlege, but
it seems like it would be simple to swap out BeanScript with BSF to gain
access to Javascript, Python, TCL, and other scripting languages, too.
This feature seems to violate another of Swixml's design goals--being
lightweight--since scripting will add to the "already sluggish behavior
of a Swing UI". Again, fair enough, each project has its own design goals.
It just doesn't seem like these two approaches are mutually exclusive to
me, though. Why not use Swixml to define the layout. Simple,
lightweight, easy-to-use. For those who are so inclined, Axualize could
be utilized to add behaviors and to extend Java classes from within XML
files. One could use either Swixml or Axualize separately, or use both
together.
Quite frankly, I don't think the changes required to each project to
support this are that great. Swixml's limited focus would mean that
Swixml really wouldn't need to be changed at all. I'd like to see
accesss to a DOM added to SwingEngine (this would allow Swixml objects
to be bound to Axualize objects using CSS, making a sort of analog to
XUL/CSS/XBL with Swixml/CSS/Axualize). But even that wouldn't be
necessary in order to make them interoperable. Axualize would need to
have some knowledge of Swixml--for instance, it might be useful to add
an Axualize tag that allowed for the lookup of components created by
SwingEngine. Another approach (the one Russell is considering, I think)
would be to add support for parsing Swixml files to Axualize. In either
case, Swixml really wouldn't need to be altered to support interoperability!
Wolf, on a separate note, could you not make Swixml far more generic
(usable with non-Swing guis, even!) if you simply used reflection to
identify the class type for tags? If that were done, there would be no
need to register tags at all. Furthermore, this would allow support for
other UIs such as SWT. You'd still need to keep the converters, but I
think that would simplify Swixml and make it more generic without
significantly impacting performance.
-dan
Wolf Paulus wrote:
Even if this might turn some developers away, I think it is import to
be very clear at this point.
While we are certainly not done developing Swixml, we will not turn it
into a JSP like programming language or general all purpose tool.
Variables, loop, etc. will not have representations in the XML
descriptors.
There a many (I repeat _many_) projects out there, open-source as well
as close source that already support those kind of things.
Swixml is not a one size fits all XML-to-GUI converter and doesn't
want to become such a things. Again, Swixml is suppose to be small and
fast; we certainly don't want to add to the sometimes already sluggish
behavior of a Swing UI. Therefore, every approach that would require
to sub-class most or even all Swing components and widgets has to be
dismissed.
The JRE 1.4.x already supports long-term persistence using
java.beans.XMLEncoder and java.beans.XMLDecoder.
http://java.sun.com/products/jfc/tsc/articles/persistence2/#jcp
For Swixml this means that there is no need to add to this persistence
mechanism, which allows to serialize complete Swing UIs into an XML
format.
Like mentioned already, Swixml is not done. I.e., we'll add action
maps, which will result in not having to subclass SwingEngine anymore.
However, the overall approach is not going to be changed or widely
expanded for the foreseeable future.
Wolf
