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

[public@xxxxxxxxx]

Wow, that sounds great!
(Steve Jobs-esque "insanely great" even :)

One question i have tho.  When you go to build your app, is the XSWT
translated into java code, which is then compiled as normal?  Or is the
XSWT intrepreted at runtime?  If the latter, what kind of component init
costs are we looking at?

Btw, I'm really loving the idea of a real-time XSWT XML editor with preview!


-- Derek Anderson
Software Engineer
http://kered.org



> 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