Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [e4-dev] Declarative UI


Your example is not really a problem with XWT. 

First of all, XWT provides a direct mapping by default. You can also add an
abstract UI model in XML and generate SWT in a different way. The only
difference is this abstract UI model is not accessible by programming API.
Please see the picture of architecture. 

Second, in your case, I think it'd better to consider Border as a UI element
since a border may have some style as well. 

Best regards
Soyatec - Eclipse OutSourcing & XAML for java
Tel: +33 1 60 13 06 67
Mobile: +33 6 20 74 39 45
Fax: +33 9 58 07 06 67

-----Original Message-----
From: e4-dev-bounces@xxxxxxxxxxx [mailto:e4-dev-bounces@xxxxxxxxxxx] On
Behalf Of Tom Schindl
Sent: Friday, December 19, 2008 2:25 PM
To: E4 Project developer mailing list
Subject: Re: [e4-dev] Declarative UI

Hi Yves,

Yves YANG schrieb:
> Hi Tom,
>> What I still say---I discussed this yesterday with Kevin on IRC---is that
> a 1:1 declarative UI definition works as long as you don't mix in CSS.
> at this very moment 1:1 fails because one might be needed to create
> effects to modify the Widget-DOM, e.g., nest a control in an artificial
> composite to show a shadow border.
> I cannot see any problem of 1:1 declarative UI with CSS. If you change the
> Style, you can simply recreate the entire tree or view. 

... but because you define that the developer codes against the 
SWT-Widget structure his code must adjust itself to this new widget 
hierarchy. But even more important is how CSS works.

To make CSS really working we need to have stable paths which don't 
change simply because an CSS property on the widget is set or not.

An example of UFaceKit:

Initial UFaceKit:
   + UIComposite
     + Text

So to get access to the Text-Widget you have a path like this:

Initial Plain SWT:
   + Composite
     + Text

So to get access to the Text-Widget you have a path like this:

Now let's add a Border and pretend that we need to add an aritificial 
Composite to provide this visual effect.

UFaceKit with Border:
   + UIComposite
     + Text

Path: /uiapplicationwindow/uicomposite[0]/text[0]

Plain SWT with Border:
   + Composite
     + Composite
       + Text


So now you might ask why this is important if you don't want to access 
the widgets using XPath anyways well the reason is that CSS works 
exactly the same where you can define styles like this:

Shell > Composite > Text {
   background-color: red;

So at the very moment you set a Border-Style to your Text-Widget the 
above stylesheet doesn't apply any more but in contrast if you would 
have defined the stylesheet against the abstract stable widget hiearchy 
of UFaceKit like this it

UIApplicationWindow > UIComposite > Text {
   background-color: red;

still applies because the path stayed the same.

> With an abstraction layer, you should have the same problem. In SWT, some
> parameters must be provided during the creation. If you want to change it,
> you have no way to do it on "live" (keep the same SWT Widget). The only
> solution is "delete it and recreate it". It is what we do in eFace and
> I cannot see any problem with this solution. 

No you don't because you program against the abstract idea of an 
text-field. As far as I have understood it until now is that in XWT I 
load the Widgets and then program against the real SWT-Widget but in 
this case if I hold an reference to the Text-Widget-Instance you just 
disposed because I remove the border-property I point to a destroyed widget.

In contrast if you program against the abstract instance the real widget 
which is disposed and recreated is hidden from you and your cached 
reference is still valid so it acts like a stable proxy.

e4-dev mailing list

Attachment: architecture.png
Description: PNG image

Back to the top