Re: [platform-swt-dev] possible XML SWT markup language?

["Chris McLaren" <Chris_McLaren@xxxxxxxxxx>]

Derek has pretty much hit on what I've
done, which I've rather blandly been calling XSWT around the office.

XSWT is a markup language for describing
composites of SWT widgets, including descriptions of the layouts, constraints,
and other properties of the widgets. XSWT tries to remain 1-1 to SWT to
reduce the learning curve. By being XML, it is ideally suited to be produced
from an XSL transformation from other, perhaps higher level yet-to-be-invented
UI markup languages.

I have put XSWT in a plugin which includes
an XML editor (thanks PDE..), and a viewer which tracks the active XSWT
editor and renders the markup on the fly using SWT controls (including
allowing you to resize the parent composite to see how the layout behaves
under resizing conditions). The viewer is not a two-way tool - you type
your XML and see what the controls look like, but you can't move around
the controls and have it change the XML for you.

XSWT does NOT go further - it does not
attempt to handle events, add scripting, or do anything else funky. Its
meant to work with java code to get anything useful done. Provided is the
service to take an XSWT resource, and build the controls inside a parent
composite of your choosing (like a dialog, for instance) in one line of
java code.

But wait, you say - If it doesn't handle
events, etc, I still need references to some or all of the widgets that
it created such that I can add my listeners..! For that reason, the above
one line of code also returns a Map (java.util) of ID strings to widget
instances. In the XSWT markup, any widget can specify an attribute called
'id' for this purpose. 

Advantages of XSWT as I perceive them:

1. Reduce code significantly. Analysis
of random preference page code in Eclipse, for instance, shows that often
2/3+ of the code is dedicated to creation of the composite. Consider a
simple example: WorkbenchPreferencePage (org.eclipse.ui.internal.dialogs).
It is 377 lines long (as I write this), of which 226 lines (line 46 to
line 272). These 226 lines can be replaced by approximately 25 lines of
XSWT code.

2. Laying out controls can be tedious
and time consuming for the developer. XSWT allows this work to be split
- a UI designer, product manager, etc. could provide XSWT markup to the
developer. XSWT markup could be passed around easily via email and anyone
with the XSWT plugin could instantly view, compare, modify, make a copy
of, etc, without having to be in a java development context.

3. Even for developers that master complex
layouts, they are still often affected by 'clerical' errors, and they usually
require a iterative code-run cycle to look at and tweak their composite
in its context, for example, running Eclipse and going to your preference
page to have a look at how its coming along. The ability to see your composite
generated on the fly should reduce time here.

All this being said, the actual code
to implement XSWT in eclipse (along with the viewer) is quite simple, and
took only a few hours to write. I'll post something up maybe tomorrow to
have people play around with it. Will
it be useful? ah, who knows..

Chris