Gerald Bauer
2005-04-26 01:35:40 UTC
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
_________________________________________
United XAML | http://unitedxaml.org
XAML Forum & News | http://xamlnews.com
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
_________________________________________
United XAML | http://unitedxaml.org
XAML Forum & News | http://xamlnews.com