| RE: [e4-dev] Declarative UI |
Tom, 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 Yves YANG Soyatec - Eclipse OutSourcing & XAML for java http://www.soyatec.com 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. 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 _______________________________________________ e4-dev mailing list e4-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/e4-dev
Attachment:
architecture.png
Description: PNG image
