[
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