Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.  But
at this very moment 1:1 fails because one might be needed to create certain
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:
---------8<---------
UIApplicationWindow
  + UIComposite
    + Text
---------8<---------

So to get access to the Text-Widget you have a path like this:
/uiapplicationwindow/uicomposite[0]/text[0]

Initial Plain SWT:
---------8<---------
Shell
  + Composite
    + Text
---------8<---------

So to get access to the Text-Widget you have a path like this:
/shell/composite[0]/text[0]
Now let's add a Border and pretend that we need to add an aritificial Composite to provide this visual effect. 

UFaceKit with Border:
---------8<---------
UIApplicationWindow
  + UIComposite
    + Text
---------8<---------

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

Plain SWT with Border:
---------8<---------
Shell
  + Composite
    + Composite
      + Text
---------8<---------

/shell/composite[0]/composite[0]/text[0]
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 XWT.
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. 

Tom

Back to the top