Why use XAML?

10May/0712

I'm looking at the SilverlightPad example for the 1.1 alpha version of the plugin. Has anyone else noticed that pretty much all XAML code exhibits the arrow anti-pattern?

PLAIN TEXT

XML:

<!---
///////////////////////////////////////////////////////////////////////////////
//
// blocks.xaml
//
//
// 2007 Microsoft Corporation. All Rights Reserved.
//
// This file is licensed as part of the Silverlight 1.0 SDK, for details look
// here: http://go.microsoft.com/fwlink/?LinkID=89144&clcid=0x409
//
///////////////////////////////////////////////////////////////////////////////
-->
<Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Height="500" Width="500">
<Canvas.Triggers>
<EventTrigger RoutedEvent="Canvas.Loaded">
<EventTrigger.Actions>
<TriggerActionCollection>
<BeginStoryboard>
<Storyboard BeginTime="0" Duration="Forever">
<DoubleAnimation Storyboard.TargetName="path1" Storyboard.TargetProperty="(Canvas.Top)" From="0" To="300" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:2" RepeatBehavior="Forever"/>
<DoubleAnimation Storyboard.TargetName="path2" Storyboard.TargetProperty="(Canvas.Left)" From="0" To="400" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:4" RepeatBehavior="Forever"/>
<DoubleAnimation Storyboard.TargetName="path3" Storyboard.TargetProperty="(Canvas.Top)" From="0" To="200" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:8" RepeatBehavior="Forever"/>
<DoubleAnimation Storyboard.TargetName="path3" Storyboard.TargetProperty="(Canvas.Left)" From="0" To="350" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:4" RepeatBehavior="Forever"/>
<DoubleAnimation Storyboard.TargetName="path4" Storyboard.TargetProperty="(Canvas.Top)" From="0" To="250" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:2" RepeatBehavior="Forever"/>
<DoubleAnimation Storyboard.TargetName="path4" Storyboard.TargetProperty="(Canvas.Left)" From="0" To="30" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:2" RepeatBehavior="Forever"/>
<DoubleAnimation Storyboard.TargetName="path5" Storyboard.TargetProperty="(Canvas.Top)" From="0" To="278" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:4" RepeatBehavior="Forever"/>
<DoubleAnimation Storyboard.TargetName="path6" Storyboard.TargetProperty="(Canvas.Left)" From="0" To="176" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:4" RepeatBehavior="Forever"/>
</Storyboard>
</BeginStoryboard>
</TriggerActionCollection>
</EventTrigger.Actions>
</EventTrigger>
</Canvas.Triggers>
<Rectangle x:Name="path1" Opacity=".65" Fill="orange" Height="100" Width="100" RadiusX="10" RadiusY="10" />
<Rectangle x:Name="path2" Opacity=".65" Fill="blue" Height="100" Width="100" RadiusX="10" RadiusY="10" />
<Rectangle x:Name="path3" Opacity=".65" Fill="red" Height="100" Width="100" RadiusX="10" RadiusY="10" />
<Rectangle x:Name="path4" Opacity=".65" Fill="yellow" Height="100" Width="100" RadiusX="10" RadiusY="10" />
<Rectangle x:Name="path5" Opacity=".65" Fill="green" Height="100" Width="100" RadiusX="10" RadiusY="10" />
<Rectangle x:Name="path6" Opacity=".65" Height="100" Width="100" RadiusX="10" RadiusY="10">
<Rectangle.Fill>
<LinearGradientBrush StartPoint="0,0.5" EndPoint="1,0.5">
<LinearGradientBrush.GradientStops>
<GradientStop Offset="0" Color="white"/>
<GradientStop Offset="1" Color="Gray"/>
</LinearGradientBrush.GradientStops>
</LinearGradientBrush>
</Rectangle.Fill>
</Rectangle>
</Canvas>

I'm not a big fan of the declarative UI movement. (XUL, Apollo, XAML, and now JavaFX). The reasons given for declarative programming usually center around making the UI code human readable making a cleaner break between the UI(view) and the controller(code driving the view). But UI's are complicated things, the code or markup used is complicated also. So what's the first thing most developers do? They go find a tool that makes sure they never, ever have to deal with the complicated markup and code. So if you're never going to read the UI code, why bother making it human readable? Apples Interface Builder has known this secret for years.

Interface Builder stores user interface resources in "nib" files. Nib files are a statically stored representation of the set of interface objects used by the application and their relationships which can be efficiently brought into memory when needed, reducing development time and making it easier to localize an application for different markets.

You could make an argument that Nib = binary XAML. The UI is "freeze dried" at design time and then reconstituted and instantiated at run time.

If you search for "Why use XAML", the pages of results never tell you what the advantage of using XAML over imperative code is. The results just say, "WPF uses it. That's why you have to use XAML".

That isn't to say there aren't some benefits to working with XAML. I love the fact that I can dump ALL my markup and UI code in one file, and concentrate on manipulating the UI in another. You could do that during standard Winforms development, but it wasn't as easy. I'm all about easy. The ability to define timelines and animations within XAML put it above the Nib format.

What benefits do you see in using XAML?

Filed under: .NET, Languages, Silverlight Leave a comment

http://www.intelemedia.com Brian

1. Editors of choice. Think of XAML in HTML frame of mind. Now you can choose editors that provide the feature set you want, or event write your own.
2. Extensibility. Since its *ML based it can be extended and grow, much like HTML, SGML and so on.
3. You can write programs that emmit XAML on the fly. A lot of the coding I do has to do with abstract dynamic UI’s. Having a framework that is easy to emmit, like XAML or HTML or SGML makes that task a ton easier. You can now apply styles and controls just take on that look and feel.

Although I agree with you on the coding issues for the time being. Until the toolsets get there, this is more of an environment that I will look forward to instead of use in prod right now.
http://www.lopezconsulting.com George

I think you are missing the point. XAML becomes the data interchange format that you can pass around between multiple tools. Easy to generate. Not too hard to read. Easy to compress if necessary. Makes it easier for designers to work with developers, etc. using their tools of choice. Would you rather have a closed, proprietary, binary-based format?
http://www.douglaskarr.com Douglas Karr

Now we know why you call yourself Lazycoder! It’s not easy to separate your UI from your middle-tier but it makes for much more flexibility. If I’m a .NET programmer, I could build one heck of an application and then make the UI ‘plugin’. That’s going to afford me much more opportunities when the next UI technology comes along!
http://www.lazycoder.com Scott

Brian: Good points, but I think the extensibility is present when you use an imperative language too. Subclassing controls to add new functionality to them or creating new controls from scratch.

Brian and George: I don’t think the interchange between tools will be important because I don’t think anyone but MS will be creating tools for building XAML. Closed, proprietary vs. Open and OSS doesn’t matter if the underlying platform isn’t really open.

The easy to understand part really doesn’t matter. If the tool is good enough, you shouldn’t ever have to read it. If I have to work on someone elses XAML, which is going to be easier? Peering over lines and lines of angle brackets and attributes? Or loading up the the XAML in Blend and and seeing what it looks like and what events are bound to which objects?
(http://www.lazycoder.com/weblog/index.php/archives/2007/04/27/people-communicate-more-effectively-visually/)

Doug: Nice, an idea for my next big post. “The myth of the plugin UI”. You never re-use UI between applications and when a new technology comes along, you almost always have to re-work the back end to take advantage of new features. Sometimes, your hand is forced into re-writing the UI or the entire app. Ask any VB 6 programmer.
http://mbrownchicago.spaces.live.com Mike Brown

Scott, what is the difference between the Winforms designer and a designer for XAML? Yes behind the scenes, the Winforms designer generates C# code that initializes your UI, it is technically human readable…but how often do you manipulate that code? The designer even puts a big Region around it saying “Designer Generated Code Do Not Edit”.

When I use Blend to create my UI, I still drop into the raw XAML to touch it up. (Just like I did with Dreamweaver/HTML before it). That’s the beauty of WPF having XML based UI declaration: it’s easy to write a tool that can generate and manipulate it, but you can still get to the raw elements and manipulate them by hand.
http://mbrownchicago.spaces.live.com Mike Brown

Also a point I forgot to mention is that WPF/XAML provides much better alternatives to subclassing controls. For instance, you can change the look and feel of a control using styling (look at csszengarden or remix07 for examples of how a styling mechanism allows for designers to do what they do best and content producers/developer to do what they do best).

You can even attach additional functionality to a wpf control without extending it. Show me where that level of extensibility exists in Winforms.
http://londoncoder.wordpress.com Jan Bannister

I think that complaining that there is tool support for xml based documents is like damning intelli-sense because now coder don´t need to memorize the entire framework library to be productive.
http://www.lazycoder.com Scott

Here is a list of XAML editors. I don’t know how good any of them are since I haven’t tried them. But it does look like people are building XAML editors outside of MS.

http://rrelyea.spaces.live.com/blog/cns!167AD7A5AB58D5FE!1695.entry
http://channel9.msdn.com/ShowPost.aspx?PostID=306592

Mike: I’d consider having to drop into the raw source to fix something a failing of the tool. Don’t even get me started on the Visual Studio Winforms designer and what it does and doesn’t let me do.

The ability to add functionality to a form without extending it exists to some extent by utilizing the decorator pattern, but I think what you are talking about won’t be possible in Winforms until extension methods are present in C# 3.0. Will Winforms even be around then? If XAML does support some kind of CSS like styling mechanism, that boosts my opinion of the underlying framework (WPF/Silverlight) but still doesn’t give me warm fuzzies about the file format.
http://www.lopezconsulting.com George

Mike, you said, “I’d consider having to drop into the raw source to fix something a failing of the tool.”

So does that mean that if we ever have (or prefer) to use the command line, that is a failing of the OS? To me, that’s a big plus that we have the option if we are so inclined.
http://www.lopezconsulting.com George

Sorry that should have been directed at Scott not Mike.
http://mbrownchicago.spaces.live.com Mike Brown

Scott, no need to worry, Winforms will be around for a while. I’ve spoken with people at MS and they’ve told me that the developer story for WPF in “Orcas” is still all about the early adopter.

Regarding dropping into raw source, you don’t HAVE to do it. I’m still at the point where I’m more comfortably hand coding XAML than using Blend for everything…I went through the same thing when I forced myself to learn Dreamweaver.

Everything is exposed to you through Blend, it’s just nice knowing that the option is there: if you want to hand code your XAML you can.

The big thing for me (and I know I’ll sound like a marketer person/evangelist), is that this is really the first time that you can separate the tasks of design and coding. I can whip a really simple UI together get it functioning properly and a designer who knows how to make stuff pretty can take those same files and work his magic.

We’re actually doing that on a project here. The developers made the engine, and we’re sending it off to a design group to make the body purdy.

If only Blend integrated with Team Foundation Server, I’d be a happy camper.
http://www.lazycoder.com Scott

George: If you prefer to use the CLI, no the tool (OS) hasn’t failed. If you have to because the GUI tool doesn’t expose some setting, then yes. The tool has failed.
I haven’t found a WYSIWYG HTML editing tool that works for me yet, so I end up editing HMTL in a text editor a lot.

Mike: Yeah, I’m sure the support will still be there since most of Winforms is composed of Win32 wrappers. But it seems to me that it’s going to stagnate while MS works on WPF. I haven’t seen any new features announced for Winforms in Orcas and my few explorations in Orcas haven’t revealed anything.
Pingback: xaml - StartTags.com