Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipse-incubator-e4-dev] Fw: Declarative UI roundup?

Hi Dave,


I think we should minimize markup extensions (x:) because they increase the difficulties for the tools to assist the code completion and decrease the clarity of the codes. I have looked at XSWT closely. It is difficult for me to find the consistence in semantic about the element name.


Element name is sometime used as UI element type, sometime used as field/property. I just noticed it could be a method. Here is an example I found somewhere (I don’t know if it is obsolete).


         <list selection="0" x:style="BORDER|SINGLE">
           <layoutData x:class="gridData" heightHint="100" widthHint="220"/>

           <add x:p0="Line number foreground"/>
           <add x:p0="Matching brackets highlight"/>
           <add x:p0="Current line highlight"/>
           <add x:p0="Print margin"/>
           <add x:p0="Find scope"/>
           <add x:p0="Linked position"/>
           <add x:p0="Link"/>


It seems the “add” is a method. It seems to me the XSWT XML is designed to find a way to serialize/deserialize SWT on XML without taking care of the model mapping. I suppose this raise some difficulties to correct with VE since VE relies on JavaBean.


Here is XAML code for the same UI:


         <List selection="0" x:style="BORDER|SINGLE">

                        <GridData heightHint="100" widthHint="220"/>



    <x:Array Type="j:String">

                   < j:String>"Line number foreground"</j:String>
                   < j:String>"Matching brackets highlight"</j:String>

                   < j:String>"Current line highlight"</j:String>

                   < j:String>"Print margin"</j:String>

                   < j:String>"Find scope"</j:String>

                   < j:String>"Linked position"</j:String>

                   < j:String>"Link"</j:String>





“j” namespace corresponds “java.lang” package. This cods uses “items” property in array of type String.



From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of David Orme
Sent: Friday, November 07, 2008 3:10 PM
To: E4 developer list
Subject: Re: [eclipse-incubator-e4-dev] Fw: Declarative UI roundup?


Hi Ed,

The original xswt design always required the x:children node so that this ambiguity couldn't exist.  I removed that requirement when I realized that the syntax didn't actually clarify anything nearly all of the time.  It simply added line noise to read past and keystrokes to type.

-Dave Orme

On Nov 7, 2008 5:33 AM, "Ed Merks" <ed.merks@xxxxxxxxx> wrote:


Comments below.

David Orme wrote: > > A node name is first converted to a setter.  If we can't find a method by th...

That's something that struck me superficially looking at XAML.  I.e., they're "just" using class names as the element names where it's more usual to use feature/property names for the elements.   Of course for attributes, people always expect feature/property names, but for elements often people are surprised that the element name isn't a type name.  That becomes more obvious when the same type of object can play a role in more than one feature.  Of course if you have a single containment feature (as in window parenting), you don't have this problem and it seems quite natural to use types for element names, especially when it allows you to avoid using "xsi:type" or defining a plethora of substitution group elements to avoid xsi:type...

> > This works nearly all the time. > > But to create a Text inside a Group becomes a problem since...

This is like xsi:type I assume.  Think of how you'd do this in JSON.  It's important to have this information early...

> >   <x:children> >     <text x:style="BORDER"> >   </x:children> > </group> > > -Dave Orme >> >> O...



> _______________________________________________

> eclipse-incubator-e4-dev mailing list

> eclipse...

eclipse-incubator-e4-dev mailing list

Back to the top