AW: [e4-dev] Why XML UI is important for us

["Stefan Roeck" <Stefan.Roeck@xxxxxx>]

Patrick, I fully agree to your points - however one should be clear about what it means to "use XAML".
>From my pov, there are two aspects:

1. XAML as serialization grammar
XAML introduces concepts like a property element syntax which basically says that
<Button Name="Click me"/>

Equals

<Button>
<Button.Name>Click me</Button.Name>
</Button>

Other concepts are content properties, markup extensions or code behind.
Adopting some of these concepts makes sense, however, they have far reaching consequences that have to be considered.
Property element syntax and content properties for instance make it hard to provide an XSD for XML-Validation.

2. XAML and WPF
You mentioned tools based on XAML. Tools that I know about (as Expression Blend) are based on XAML+WPF. That's a difference. I don't think that it makes sense to adopt WPF's widget model and even if one would do so, I doubt that using Expression Blend for designing Eclipse UIs would be possible.


I agree that using existent standards is a desirable goal. However, in case of XAML I can only imagine of taking concepts and use them (examples mentioned above, maybe Binding syntax, too). Being 100 percent compatible is not realistic.

Regards,
Stefan.


-----Ursprüngliche Nachricht-----
Von: e4-dev-bounces@xxxxxxxxxxx [mailto:e4-dev-bounces@xxxxxxxxxxx] Im Auftrag von Patrick Paulin
Gesendet: Dienstag, 13. Oktober 2009 19:19
An: E4 Project developer mailing list
Betreff: Re: [e4-dev] Why XML UI is important for us

I'm glad to hear that the participants in this thread are going to get  
together at ESE and work through these issues. Meeting face to face  
often makes these discussions much easier :)

Unfortunately I can't attend ESE, so I wanted to provide my input  
here. I hope you'll consider these points when you're making final  
decisions. In my opinion, there are really two questions here:

1. What should the default UI construction experience be for Eclipse  
developers?
2. How can we maximize the UI framework's power and flexibility to  
allow for future innovation?

My answer to #1 is that the default UI mechanism should be standards- 
based and declarative. I've worked with and trained many RCP  
development teams. These teams often struggle to learn the many APIs  
that make up Eclipse RCP. The more we can incorporate familiar  
solutions into RCP, the easier it becomes for teams to adopt it. Many  
of the teams I talk to are very interested in declarative UIs, and I'd  
say that most of them would be very happy with XAML + CSS. Remember  
that this thread began with an RCP user saying how excited they would  
be with a declarative UI. Please listen to these users.

Choosing XAML as the default developer experience also allows us to  
leverage existing resources. There are books on XAML. There are tools  
that work with XAML. Vendors will be more interested in creating new  
Eclipse tooling for XAML. .NET developers will be tempted to try RCP,  
and they might be able to migrate some of their existing UI elements  
as well. In short, we should always be looking at how to leverage  
existing standards to build momentum. This is what we did by adopting  
OSGi, and we should be looking to do the same thing in the UI space.

But how do we address question #2? Well, saying that XAML is the story  
we tell developers new to RCP does not mean it has to be the only  
story. If we can back the declarative UI with an EMF model and this  
can be made transparent to most developers, I say we do it. If this  
makes possible competing approaches and tools for UI construction, so  
much the better. If the model evolves into a superset of what's  
provided by XAML, that's fine. But please let's start with the  
mechanism that developers already understand and work back from there.

Like the RCP user that started this thread, I'm really excited about  
what's happening with e4 and I think it has the potential to  
drastically increase the number of developers using this technology.  
Keep up the great work!

Thanks,

--- Patrick


Patrick Paulin
Eclipse RCP/OSGi Trainer and Consultant
Modular Mind, Ltd.

patrick@xxxxxxxxxxxx
608.213.4169
www.modumind.com

twitter.com/pjpaulin
linkedin.com/in/pjpaulin



_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev