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: [email protected] [mailto:[email protected]] 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. [email protected] 608.213.4169 www.modumind.com twitter.com/pjpaulin linkedin.com/in/pjpaulin _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
