[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-swt-dev] possible XML SWT markup language?
|
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