MyXAML Lead Weighs In on MSXAML Debate

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