XUL Titan Interview with Dave Orme (of XSWT fame)

Hello,

  Welcome back to the XUL Titan Interview series.
Today let's welcome XSWT and Eclipse Visual Editor
project lead Dave Orme.


Q: Can you tell us a little bit about yourself?

Dave Orme: I have two boys: Jonathan who is 4 months
and Daniel who is 3 years old.  My favorite hobbies
are guitar and piano.  I'm much better on guitar than
on piano.  :-)

My first computer was an Apple //e; the first computer
I programmed was a 4K Apple ][+. :-)  So I pretty much
grew up with the PC industry.  In spite of that, while
doing my grad work, I was required to use Unix
workstations, and I have grown very fond of Unixes in
general and Linux in particular when I have to get
real work done in a hurry.

Currently I work for db4objects (http://www.db4o.com),
an incredibly cool company with a very cool
open-source (GPL) object database.  I suggest that you
read the tutorial that is included when you download
db4objects.  I think you'll be blown away with how
simple and easy it is to load, save, and query regular
Java objects.  And db4objects is very fast, is fully
transactional, supports schema evolution, and can
operate in either an embedded or client/server mode. 
At just over 300K JAR 
file size, it's a whole lot of features for very
little cost.  (And commercial licenses are very
inexpensive, if you want or need that.)

I also lead Eclipse's Visual Editor Project, probably
the best open-source GUI builder other than perhaps
Glade, a GTK+ GUI builder for Linux.

And, oh yeah, I lead the XSWT project.


Q: How did you get started on XSWT? Did you look into
 any XML UI language alternatives before settling on
 XSWT? Can you tell us a little bit about XSWT's
history?

Dave Orme: Chris McLaren, a developer in Eclipse's
Platform/UI project had this brainstorm about how to
build an XML language that literally just wrapped
native Java and SWT code in an XML syntax.  The
resulting files are easier to read, easier to type,
and more friendly to editing operations like cut and
paste then the Java code to do the same thing, while
being approximately 33% more compact.  And because of
the 1:1 
mapping between XSWT elements and Java, once you
understand the XSWT language, all you need in order to
code it is the SWT JavaDoc.

Chris reported his findings on the Eclipse.tools
newsgroup and in Bugzilla.  At the time I was looking
for a language for persisting SWT GUI builder layouts,
and the 1:1 mapping between SWT and Java constructs 
and the XML in XSWT was exactly what I needed.  The
fact that XSWT is easily human-editable as well as
computer-editable made it even more perfect.

After a bit of debate about it on Eclipse's Bugzilla,
Chris and the JFace team apparently lost interest. 
But I had started using XSWT to write test cases and
to prototype GUIs, so I needed it to be maintained. 
Nobody else was doing it so I did it.  :-)

After I adopted XSWT, the first thing I did was to
rewrite the engine to use Java reflection.  Chris's
implementation was totally hard-coded.

Over the years, we have added features to XSWT here
and there to support Eclipse's JFace data binding
framework (without creating an explicit dependency on
it) and to support some more esoteric SWT use-cases. 
There are now very few SWT use-cases that can't be
coded in XSWT.

Recent work has focused on making XSWT its own style
sheet language and discussing how best to add GUI
builder support.

There is a high probability that XSWT will merge into
Eclipse's Visual Editor Project.  We started some
preliminary work to do that this past week when
several of the VEP team met face-to-face at
EclipseCon.

However, this work won't happen quickly unless someone
volunteers to help do it since my personal top
priority is to begin documenting Visual Editor Project
APIs.

Q: Can you briefly sketch out XSWT's architecture and
 its building blocks?  

Dave Orme: XSWT is built on the KXML XML parsing
engine.  This is so that XSWT can run on j2me devices
and other Java platforms where Java's XML engine 
doesn't run.

On top of that is the XSWT engine itself.  It is
basically a recursive descent parser that uses the
KXML engine to get tokens.  It then uses two sets of
strategy pattern objects to actually turn those tokens
into Java objects: IDataParser and ILayoutBuilder.

IDataParser is an interface for things that know how
to convert XML tag names or attribute values into
arbitrary Java or SWT objects.  There is a single
IDataParser for each data type XSWT knows how to parse
and a registry for looking up these strategy pattern
instances based on the expected data type.  XSWT does
type inferencing whenever possible so you don't
usually have to explicitly specify data types, yet the
language 
is still type-safe as much as possible.  One nice side
benefit of current IDataParser implementations is that
the ColorDataParser and FontDataParser maintain caches
of SWT Color and Font objects so that you don't have
to worry about managing or disposing of them yourself.

An ILayoutBuilder knows how to resolve an SWT class
from its name and how to construct SWT controls based
on constructor data types.  I originally created this
pluggable interface so that XSWT could have a back-end
that generates Java source code instead of creating a 
UI--making it easy to build an XSWT to Java source
code translator.  We also expect to use this
capability to support GUI builders like Eclipse's
Visual Editor Project.

Q: Can you tell us how you handle the mapping from
 XML tags/attributes to SWT classes/properties? Do you
 use reflection? Do you use hand-coded glue code?
  
Dave Orme: Everything is done using reflection.  The
only thing that is hand-coded is the code that tries
to find an appropriate SWT constructor because
different places in the SWT class hierarchy use
different abstract classes as the parent parameter.

The benefit is obvious: we automatically support SWT
controls that haven't even been imagined yet.  Nobody
has to update a DOM or write a BeanInfo object or
anything.  It's all automatic.

Q: Can you tell us some challenges you faced creating
 a toolkit that lets you create Eclipse SWT UIs using
XML?
  
Dave Orme: The biggest challenge was in recognizing
that Chris McLaren had invented a really good solution
for SWT.  I was expecting something really generic
like the XML code produced by Java's XML persister. 
So I 
didn't see the simplicity and brilliance of Chris's
solution right away.

The second biggest challenge has been sticking to
Chris's original design.  Sometimes it's easier
short-term to add a feature to XSWT itself and then we
find that the feature would best be implemented as a 
layer on top of XSWT so that XSWT can remain what it
is: simple, lightweight, and convenient.  And so that
the programmer doesn't have to pay in performance or
memory the cost of the additional feature if s/he 
doesn't use it.

Q: What's the hook? Why would anyone use XSWT over
 say good old Java SWT coding?
  
Dave Orme: I mentioned some of these above, but,
here's what I find so compelling about XSWT:

* Approximately 33% code reduction over hand-coded
Java based on actual measurements.

* More readable and maintainable code.  This is
because the containership hierarchy is explicit in the
XML representation rather than constructed dynamically
through procedural code.  This lets you see 
at a glance what controls are contained inside of what
other controls rather than having to read the code and
figure it out.

* Ability to cut, copy, and paste in the XML file and
have the results make sense without having to mess
with parent parameters or add() methods, again due to
the containership hierarchy being explicit in the XML
representation.

* No need to learn a separate vocabulary since XSWT
just uses SWT via Java reflection.

* XSWT to Java compilation eliminates performance
concerns related to the extensive use of
java.lang.reflect APIs.  Or you can just embed the 
XSWT engine if you're running on desktop class
hardware or better.

* Liberal licensing terms under the Common Public
License.

Q: What's your take on adding CSS support to XSWT for
 styling using rules?

Dave Orme: Currently we implement CSS color name
constants for specifying colors.  Beyond this, we
think that XSWT can be its own stylesheet and
component 
language but we haven't implemented it yet. 

Here's the general design idea though:

Basically a style sheet specifies new default
attribute values for controls.  For example:

<label x:styledef="redLabel" background="red"/>

in a stylesheet would define the "redLabel" style
which would automatically change the background
property to red for any label it was applied to. 

You can apply this style to an object by referencing
it in the x:style meta-attribute:

<label x:style="redLabel"/>

will create a red label.

In this version of the proposal, the only thing we've
added to the XSWT language in order to support
CSS-like functionality is the x:styledef
meta-attribute to define styles.  x:style is already
present for 
specifying SWT style bits, so conceptually it's a nice
thing to overload for applying CSS styles.

The advantage to this approach is that if you know
XSWT, you already know how to write styles for it. 
It's really simple and easy and XSWT can reuse large
chunks of its own code to implement this feature.

Q: Do you have a favorite scripting language for the
Java runtime? Any plans for adding support for
scripting to XSWT?

Dave Orme: No and no.

Perl is my favorite scripting language, but it's not
available for the Java runtime.  On the other hand, I
like a lot of what I've seen in Ruby, but I haven't
ever had a real occasion to use it either.

Regarding adding scripting inside XSWT proper: XSWT
intends to stay as small and simple as possible.  It
also is designed to encourage a strict separation of
content, style, and functionality in an application. 
We believe that mixing scriptlets into XSWT would
violate this.

I am open to being convinced otherwise by sound
argumentation on the mailing list.  :-)

On the other hand, I would welcome people to
contribute binding layers to enable XSWT to be
conveniently used with their favorite scripting
languages (like JRuby, Jython, etc.).

Q: Do you have any plans of adding web-style form
 submission tags to XSWT? What's your recommended
 approach for data-binding for XSWT?
  
Dave Orme: The week before EclipseCon, the Remote Rich
GUI project was announced on the XSWT mailing list
(www.retrogui.com).  This project implements web-style
form submission as a layer on top of XSWT.

As far as data binding goes, at runtime, XSWT provides
direct access to the underlying SWT controls.  The
current model is to use Eclipse's JFace library (part
of the Eclipse Platform project) or Essential Data 
(http://essentialdata.sourceforge.net) to do data
binding.  Unfortunately, Essential Data was created by
my former employer, who has not allowed me to support
it based on the non-compete terms of my employment
agreement.  But they are not maintaining it either. 
So 
Essential Data currently is mainly useful as a source
for ideas for data binding frameworks.

Q: Any plans of supporting different UI toolkits such
 as Swing, wx4j or Java Gnome, for example? Or do you
 plan to stick to SWT?
  
Dave Orme: We have talked about supporting Swing.  It
wouldn't be that hard to do with the current
infrastructure.  But none of us are interested in 
Swing personally so it will probably require somebody
stepping forward and doing the work.

The official answer is that all reasonable proposals
will be considered.  Proposals that include working
code will be given the highest priority.  :-)

Q: Can you tell us how popular XSWT is? (e.g. How
 many downloads? Are there any applications/projects
 using XSWT? What's the interest in the Eclipse/Java
community? etc.)
  
Dave Orme: Given that XSWT is a single-toolkit
language and doesn't try to do all the things that XUL
does, XSWT did really well in the Richmond Post XML
language toolkit poll with 11% of the votes, putting
it in 4th 
place in the poll.

But in spite of this, I do not believe that XSWT
currently very widely used or deployed, mainly due to
the lack of time by the core developers to really
promote it.  We really appreciate Gerald giving me
this 
opportunity to talk about XSWT.  :-)  And if we can
get Eclipse Visual Editor support, that should change
a lot of people's perceptions of it. :-)

Having said that, the other ironic reason why XSWT
doesn't get talked about a lot is because it has grown
pretty mature so it's not changing a lot.  There are
three core committers on the team with real projects 
using it, and I haven't seen a bug report in a long
time.  And there's the Remote Rich GUI project that
uses it now.  I use XSWT every day in my work writing
a db4objects database front-end, and it does
everything 
I need it to do right now.  So XSWT seems to be here
to stay, with enough people interested in it and using
it that the project doesn't really need me any more to
keep going.  And that's a good thing.  :-)

Q: Who else is behind XSWT? Do you work on your own?
 How much time do you spend on XSWT development? How
 can someone get involved in XSWT?
  
Dave Orme: There are two other XSWT committers:

Jan Peterson (independant, Switzerland)
Yu You (Nokia, Finland)

We work in fits and starts as we individually have
time and/or need.  I started maintaining XSWT because
I needed it professionally and I suspect the same is
true for Yu and Jan.  As I mentioned above, since  the
engine is pretty mature now for the current feature
set, there hasn't been much new development on the
engine going on recently.

You can get involved with XSWT by using it, by joining
the XSWT mailing list, by promoting it, and by helping
to write code.  The two big areas that aren't done are
Eclipse Visual Editor Project support and style 
sheet support.

So for example, if you need something like XSWT but
*have* to have style sheet support, you will have a
much easier time adding style sheet support to XSWT
along the lines I described than rolling your own 
solution.  Similarly, if you want something like XSWT,
but *have* to have GUI builder support, I can't
imagine an easier way to get what you need than by
helping us add XSWT support to Eclipse's Visual Editor
Project.

If you're interested in either of these projects of
you have some ideas of your own, please email the
mailing list and we'll be glad to help.

Q: What's next for XSWT?
  
Dave Orme: I really want to get Eclipse Visual Editor
Project supported some time in 2005. ;-)  I think it
will be a great addition to VE and will be a  great
example to others showing how VE can be extended to
support new languages.  Plus it will give XSWT great
visibility in the community.  
The two projects could have a lot of synergy together.

In the future, I'd like to have Visual Editor Project
factored so that you could embed a GUI builder based
on XSWT in any arbitrary Rich Client Platform
application and not require Eclipse's Java compiler or
IDE at all.  This would a be really powerful way to
add custom user interface design capabilities to OLAP
and BI systems.

But "The best way to predict the future is to invent
it."   

Thank you Dave Orme for taking time out to share your
thoughts. Keep up the great work on XSWT.

Links:

- XSWT @ http://xswt.sourceforge.net
- Eclipse Visual Editor Project @
http://www.eclipse.org/vep

_____________________________________
XUL News Wire - http://xulnews.com
XUL Alliance  - http://xulalliance.org




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click