Hello,
Marc Clifton who leads the MyXAML project weighs in on the MSXAML debate and writes in the MyXAML blog:
Allow me to chime in on something Joe said:
"XAML provides for very clear and distinct separation of data, functionality, and presentation via explicit parts of the language" and also:"[XAML] goes a long way toward declarative programming, and provides some very nifty ways of making sure the two stay separate".
I find this a bit difficult to swallow and that quite the opposite to be true. A XAML application is an entangled mess of UI state management via property triggers, data binding, and UI definition. Look at a typical example and you'll see the entanglement of binding (data), property triggers (functionality), and presentation (object graph). I don't think this helps the concept of declarative programming. It looks more like an example of “how not to write applications“ if it were written imperatively. But then again, this is pretty typical. Just pop open the Visual Studio designer and start adding data sets and SQL connections and you get code that is the antithesis of what Microsoft recommends with their application blocks. It looks like XAML isn't going to be any different. You CAN do declarative programming that way, but a serious programmer would cringe.
I think there's a lot of great things that can be done with xml and object graph mapping, but to entangle property triggers and data binding along with the object graph representation is not good architecture. And frankly, as I gain experience with MyXaml applications, I'm also concerned with DIRECT xml element/attribute to class/property mapping. The resulting xml is too dependent on the underlying class/property definition. While you can do cool things with it (and it is a tool, after all), there's a lot to be said for defining a schema that is INDEPENDENT from the underlying class definition. I'd love to see what happens to XAML applications build with Avalon 1.0 running under Avalon 2.0. If there are changes to class names, properties, or even their functionality, XAML code will break just like imperative code. However, if Microsoft had chosen to abstract XAML and actually create a schema that can be nailed down, then there would be good decoupling.
Oh wait, but then you'd have an SVG clone. :)
Another benefit to a well defined schema is you can then plug in different toolkits. In fact, you can use toolkits that aren't declarative programming friendly by writing a wrapper layer specifically for that toolkit. If you want to use a different toolkit later on (like a docking manager, or a planner control, or a data grid control) or if you want to support a different platform (like web), then there's some chance at least that the same schema can be used regardless of implementation.
Oh wait, but then you'd have something like GTK# or QT# or many of the other XUL motors.
With MyXaml, I'm looking at a compromise--using xml element/attribute to class/property mapping for things that are mostly “stable“ (like .NET), but writing wrapper classes for things that aren't as stable, like third party toolkits. We'll see how it goes.
So, my point is, don't be fooled that XAML goes a long way toward declarative programming. It doesn't. As other posters commented, it's just a serialization format. Treat it as such.
Source: http://myxaml.com/marcclifton/archive/2005/04/25/1938.aspx
Any comments?
- Gerald
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ xul-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xul-talk
