[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] possible XML SWT markup language?
|
My experience with using dynamically interpreted XML has been that there is
no noticeable overhead. That was with an XML <-> Swing transformation
schema, and used a dynamic mapping onto proxies in a controller (a la NeXT's
UI builder).
Mistakes we made ...
1. Should have identified common resources and factored those out to be
re-used across UI's (fonts, images etc)
2. Containment relationships (layout info) were interwoven with the property
assignments. IMHO this made the use of XML a bit redundant as we ended with
a descriptor that was potentially more complicated than generated code -
albeit one that was easily readable by a UI editor.
3. Poor/incomplete support for reuse of aggregated components.
Thinking of these in terms of markup, our schema was more like classic HTML
with everything woven together, whereas we should have been aiming for
something closer to a CSS/XHTML split.
Hope these comments help.
JB
----- Original Message -----
From: <public@xxxxxxxxx>
To: <Chris_McLaren@xxxxxxxxxx>
Cc: <platform-swt-dev@xxxxxxxxxxx>
Sent: Thursday, May 22, 2003 8:37 PM
Subject: 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
>
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
