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"/>
</list>
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">
<List.layoutData>
<GridData
heightHint="100" widthHint="220"/>
<List.layoutData>
<List.items>
<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>
</x:Array>
</List.items>
</list>
“j” namespace corresponds “java.lang”
package. This cods uses “items” property in array of type String.
yves
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:
David,
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
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev