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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> 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
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
