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
