I add some explanations for my XAML code:
1. The simple element name (<Composite>) corresponds to a class name.
2. The qualified element name (i.g. <Composite.layout>) corresponds to
a property defined by an element.
3. The default namespace corresponds to system packages.
4. User defined package can be declared as a namespace in the format:
clr-namespace:<package>=<jar>
If we bind the text of label to a property Name of a Person, here is the
data binding expression:
<Label text="{binding path=Name}"/>
It has the same result as following, but the expression is in pure XML:
<Label>
<Label.text>
<Binding path=Name/>
</Label.text>
<Label>
Yves
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Yves YANG
Sent: jeudi 6 novembre 2008 22:59
To: 'E4 developer list'
Subject: RE: [eclipse-incubator-e4-dev] Fw: Declarative UI roundup?
Here is the complete example in XAML
<Composite xmlns=http://www.eclipse.org/swt/presentation
xmlns:x=http://www.eclipse.org/swt>
<Composite.layout>
<GridLayout numColumns="2"/>
</Composite.layout>
<Label text="Hello, world"/>
<Text x:style="BORDER">
<Text.layoutData>
<GridData horizontalAlignment="FILL"
grabExcessHorizontalSpace="true"/>
</Text.layoutData>
</Text>
</Composite>
In case, if you have your owner layout named as ui.MyGridLayout, the code
will be:
<Composite xmlns=http://www.eclipse.org/swt/presentation
xmlns:x=http://www.eclipse.org/swt
xmlns:y=cls-namespace:ui>
Xmlns:y=http://www.eclipse.org/swt
<Composite.layout>
<y:MyGridLayout numColumns="2"/>
</Composite.layout>
<Label text="Hello, world"/>
<Text x:style="BORDER">
<Text.layoutData>
<GridData horizontalAlignment="FILL"
grabExcessHorizontalSpace="true"/>
</Text.layoutData>
</Text>
</Composite>
yves
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David
Orme
Sent: jeudi 6 novembre 2008 18:11
To: E4 developer list
Subject: Re: [eclipse-incubator-e4-dev] Fw: Declarative UI roundup?
Since I won't ask someone to do something I won't myself do, :-) here's a
slightly-enhanced Hello, world in XSWT, eliminating the XML boilerplate and
imports:
<layout x:class="gridLayout" numColumns="2"/>
<label text="Hello, world"/>
<text x:style="BORDER">
<layoutData x:class="gridData"
horizontalAlignment="FILL"
grabExcessHorizontalSpace="true"/>
</text>
This is functionally equivalent to:
parent.setLayout(new GridLayout(2, false);
Label label = new Label(parent, SWT.NULL);
label.setText("Hello, world");
Text text = new Text(parent, SWT.BORDER);
text.setLayoutData(new GridData(GridData.FILL_HORIZONTAL |
GridData.GRAB_HORIZONTAL));
(This actually translates to:
GridLayout gl = new GridLayout();
gl.numColumns = 2;
parent.setLayout(gl);
Label label = new Label(parent, SWT.NULL);
label.setText("Hello, world");
Text text = new Text(parent, SWT.BORDER);
GridData gd = new GridData();
gd.horizontalAlignment = SWT.FILL;
gd.grabExcessHorizontalSpace=true;
text.setLayoutData(gd);
)
If you could translate this to XAML, Yves, that might be a useful place to
begin comparison.
Regards,
Dave
On Thu, Nov 6, 2008 at 8:02 AM, Yves YANG <[EMAIL PROTECTED]> wrote:
So let's compare the two directions: abstraction model UI and SWT Centric
1. SWT Centric
This approach consists of mapping directly from XML <-> SWT. It is true SWT
is already an abstraction of the different UI technologies: Win32, GTK, etc.
But it is low level abstraction: UI Widgets. It doesn't cover more advanced
concepts.
Could someone tell me why Eclipse invents a new UI Library SWT, instead of
using Swing, which is already cross platform? From my point of view, SWT
respects the native Look and Feel, particularly, in Windows. And Swing had
some problems of performance, ugly look and complexity in development. This
is a good example of courage to replace the out-of-date solution by a new
one. Are we in the same situation? SWT is designed mainly to create the UI
via programming. It is created several years ago. Its API doesn't full
respect neither the model constraint, non JavaBean specification. Using it
as main model, the new component will inherit its limitations and we have to
add outside components to support other features such as style, data
binding. Does it become a hybrid framework?
Since the birth of SWT, the UI technology evolves quickly to markup
language. Microsoft has the courage to give up the Win32 and invent a new
component-based framework WPF for providing common and full integrated UI
platform not only for Developer, but also for graphic designer and business
analyst. It focuses on content presentation, instead of low level basic UI
widgets. It really simplifies the UI Development.
I think SWT should stay where it is designed for.
2. Abstract UI model
Simply, it will give us a new land with maximum freedom to develop a
complete, extensible UI "Presentation" Framework.
Just a thought
Best regards
Yves YANG
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kevin
McGuire
Sent: Thursday, November 06, 2008 12:32 AM
To: E4 developer list
Subject: Re: [eclipse-incubator-e4-dev] Fw: Declarative UI roundup?
Great discussion guys. I'm only beginning to understand this area and the
thread has been helpful. Actually my hope for the roundup is exactly this
kind of shared understanding of the technology, and some common view of the
goal.
> The UI model tries to abstract
> away the underlying technology by focusing on what information a widget
supports
> (input/output), rather than the widget API. This makes the model
> toolkit-independent, but the runtime of course needs toolkit-dependent
code to
> control the life-cycle of the real widgets.
Hallvard, I admit that I know nothing of your research so I'm just going to
speak quite generally, which may not at all match what you're doing:
I find this theoretically cool but with my practical hat on I'm trying to
understand the benefit this added abstraction buys us in Eclipse. My
original thinking was that the declarative language should map 1:1 to SWT,
because its SWT that actually does, well, the useful stuff. The buck stops
there. Either you can have list of strings, or a list of rendered strings
plus images, or owner draw ... its in the capabilities of the widget and the
only way to get stuff on the screen. In fact one can regard SWT as this
exact toolkit independent model (if we think toolkit=platform) because it
attempts to isolate you from platform specifics, thus the SWT list widget is
already that abstraction of the concept of a list widget across all
platforms. It just happens to be API based, not declarative.
My concern is that inevitably when you go to an abstraction, you inherently
lose some fidelity. Maybe some capability of a particular system you care
about (in this case, SWT) can't be expressed because your model is a common
subset. Or, the model is a superset, in which case you write in the hopes
of something happening which doesn't on your particular platform. We often
see the former case and sometimes the latter in SWT. Since I've already
lost fidelity in SWT vs. the platform, I'm hesitant at losing more through
another abstraction.
Yves, I have a similar concern around the use of XAML since I may lose
fidelity in going to SWT, but that's perhaps more a statement of my
ignorance of XAML.
Thus my thinking was perhaps along the lines Tom outlined: a declarative
model written against SWT, exposing accurately the capabilities of SWT but
in a serializeable format instead of Java code, providing a model which
facilitates mapping to other declarative models.
So I question, why do I need yet another abstraction? I guess it would let
me go to Swing, which personally I'm not interested in. Maybe it would allow
me to go the web, but SWT is going to do what it always does and treat it as
a platform. Unless you believe there is an inherent flaw in doing so which
a common abstract model solves? I suppose it could allow me to reuse parts
of UIs (e.g. some pre-canned wizard pages), but in my experience you always
roll a UI that is specific to a problem area. Finally, it allows me to
escape a particular programming language, (Java, yeah!) but I think I get
that from the declarative aspect, not the common abstraction. What am I
missing here?
> The main problem with going through XML and a renderer, is that it only
handles
> the creation process. I still need (in my case) SWT-specific code for
attaching
> listeners and activating/deactivating widgets.
<naiveQuestion>Isn't this solved to a great degree through the use of
databinding?</naiveQuestion>
Regards,
Kevin
Hallvard Trætteberg <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
11/05/2008 09:00 AM
Please respond to
E4 developer list <[email protected]>
To
E4 developer list <[email protected]>
cc
Subject
Re: [eclipse-incubator-e4-dev] Fw: Declarative UI roundup?
Tom and others,
Just a bit of background: My research field is model-based UI design and the
last years I've been building a UI modeling tool (see
http://www.idi.ntnu.no/~hal/research/
<http://www.idi.ntnu.no/%7Ehal/research/> ). The editor is based on EMF+GMF,
while
the runtime is built on a Apache SCXML (a statechart engine) for activation
of
UI parts, EMF databinding for dataflow, XSWT for describing the concrete UI,
EMF
for modeling the domain and Javascript (Mozilla Rhino) for scripting (both
behavior of the model and scripting of XSWT). The UI model tries to abstract
away the underlying technology by focusing on what information a widget
supports
(input/output), rather than the widget API. This makes the model
toolkit-independent, but the runtime of course needs toolkit-dependent code
to
control the life-cycle of the real widgets.
To make the runtime a bit more flexible, it does not build the widget
structure
directly, but generates an XML file (in my case XSWT) that is then rendered
by a
library. The idea is that it should be fairly easy to use any XML-based UI
description language.
The main problem with going through XML and a renderer, is that it only
handles
the creation process. I still need (in my case) SWT-specific code for
attaching
listeners and activating/deactivating widgets.
> b) Ed is right I think we need a more strongly typed / constrainted
> description language.
Strongly typing is desirable. But just as important is a uniform way of
manipulating the widget structure. By using DOM or EMF, we can manipulate
and
listen to standardized objects. The mapping to the toolkit API is handled by
a
toolkit-specific library, containing all necessary toolkit-specific logic. I
believe this is Angelo's approach, although he uses DOM rather than EMF.
> As I have understood TK-UI so far it uses XUL to described the UI so
> Angelo has a constrainted description language it only misses an
> Ecore-Description [1,2].
>
> What I often thought about is that we could have a layered approach here:
>
> XAML XUL MXML MySpecialML
> | | | |
> ------------------------------
> |
> | Transform (XSLT, ....)
> |
> SwtXL => EMF-Modeled SWT-API
> |
> SWT-Application
>
> This is the concept I currently have in mind for my UFaceKit-Project the
> only thing I replace there is SWT through UFaceKit and SwtXL through
> UFaceKitXL.
I don't like the idea of having an SWT-specific model, so UFaceKitXL (EMF
model
of UFace widgets) is preferable. I guess it is more difficult to make a
toolkit-independent model for UFaceKit than one for SWT? E.g. how do you
handle
things like content providers and cell renderers/editors?
As mentioned, the model is one thing, how it reacts to changes is another.
Is
UFaceKitXL designed to handle changes to the Ecore objects, like
adding/removing
widgets, changing attributes etc? I have implemented good support for Ecore
in
Mozilla's Javascript, so being able to manipulate the UI through Ecore has
great
potential.
> I've already tested this approach in a project I had named EXSWT the
> only thing missig there was the Ecore-Model for EXSWT [3].
Which was based on XSWT, wasn't it? I've worked a lot on and with XSWT and
its
main problem is that (although the language is/looks declarative) it is not
designed to handle a live model, i.e. react to changes to the DOM.
Hallvard
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
