Forgive me for chiming in here, but I'd like to add my 2 cents worth
here. I've been evaluating most of the XML-based Java guis recently,
and I think I may have some insight on this topic.
Russell, I think you may be mistaken that changes to Swing may be
difficult to support in Swixml. Swixml is pretty small and
lightweight--the only thing necessary to support new Swing classes (or
user-extended Swing classes) is a new call to regsiterTag()--just one
line of code. If new complex data types are added, new converters will
need to be created, but this really isn't that great a task. Methods
are handled through reflection, so there is no extra effort required to
support the invocation of new methods in new interfaces.
Wolf, I think Russell may have a point here about the JSR57 schema,
though. In a loose sense, Swixml really is a sort of serialization
language for Swing. In fact, if you added the letter "J" in front of
the tag names, I think you could even use reflection to find the Swing
classes themselves, thus removing the need to register tags altogether.
Swixml has done a *really* nice job of keeping it simple--its syntax is
simpler than JSR57 (its scope is narrower, too). However, JSR57 really
isn't that complex. And it is a standard. And it supports non-Swing
objects, as well. I think there may be some merit in supporting the
JSR57 schema.
This would change Swixml greatly. Right now Swixml consists of only
about 20 classes. This is small, and if Swixml decided to stay with its
schema, I can understand it on this basis alone. Changing Swixml to
support JSR57 would really mean then end to Swixml and the beginning of
something new.
That said, I really think JSR57 has something. I think Russell is
correct in saying there is no value added to having yet another
XML-based serialization language (what Swixml is, really--it performs a
sort of deserialization translating the Swixml code into a Swing GUI).
Besides, JSR57 supports so much more than just Swing. Looking at the
resulting XML, I don't think it's really any more difficult than Swixml.
What if Swixml were to introduce a new interface called "ObjectEngine"
and make SwingEngine implement it? Then the Axualize group could make a
JSR57Engine or something. Hell, my previous request for a
namespace-capable SwingEngine could be a simple extension of
SwingEngine, too. Yeah, it would take some effort. But I think the
JSR57 schema has some strong benefits. I'm not sure what extra support
would be necessary, but it seems to me that this approach might even
allow co-mingling of Swixml and JSR57 files in the future (I'm also not
sure of the benefit of this beyond backwards compatibility, and Swixml
really isn't that old yet).
I really like Swixml, as much for what it isn't as for what it is. But
I also think JSR57 deserves a closer look.
-dan
