Cross-Training in Silverlight and Flex – XAML vs MXML

More Cross-Training in Silverlight and Flex

Shout it

Silverlight and Flex both include a declarative markup language for their UIs.  Microsoft calls the Silverlight specification Extensible Application Markup Language (XAML pronounced zammel).  Adobe calls the Flex specification MXML which is thought to have come from the original inventors: Macromedia extensible Markup Language.

In either case, these markup languages share two strong characteristics: They are both based on XML and they both do a fine job of declaring the UI.


You use XAML in Silverlight to define the user interface in a declarative way.  XAML is nothing more than XML with some Silverilght namespaces that let you represent a visual tree.  Following is an example of MainPage.xaml.

<UserControl x:Class="Hello_World.MainPage"
             Width="300" Height="36">

    <Border BorderThickness="5" CornerRadius="5"             BorderBrush="Black" Height="Auto" Width="Auto">
        <StackPanel Orientation="Horizontal">
            <TextBox Width="100" Name="Input" Margin="3" />
            <Button Content="Say Hello" Click="SayHello" Margin="3" />
            <TextBlock Name="Output" Margin="3" VerticalAlignment="Bottom" />


The MainPage UserControl uses this XAML code to define the entire view.  A Border houses three UI components stacked together: text input, a button to do something with and a label to show the output.  If you were to type this into your MainPage control in Silverlight, it would look like this in your browser:


Of course, the declarative XAML is nothing without some imperative behavior. Visual Studio, generates a corresponding “code-behind” whenever a UserControl is created. In the simplest of cases, you place your behavior in the “code-behind” file. In this case, the file is named MainPage.xaml.cs.  By default, it creates a constructor for you that calls InitializeComponent().  I added the SayHello method that will get called whenever the button (defined in the XAML) is pressed.

public partial class MainPage
    public MainPage()

    private void SayHello(object sender, RoutedEventArgs e)
        Output.Text = "Hello " + Input.Text;

Most XAML introductions get off the train at this point. This series aims to show the differences between Silverlight and Flex so I will continue on to describe how the XAML and the C# code get glued together.

Notice in the “code behind” that the class it generated is a partial class.  This means that there is more to this class somewhere else.  Digging deeper into the obj/Debug folder, you will find an intermediate file named MainPage.g.cs.  It holds the rest of this partial class:

public partial class MainPage : System.Windows.Controls.UserControl {

    internal System.Windows.Controls.TextBox Input;
    internal System.Windows.Controls.TextBlock Output;
    private bool _contentLoaded;

    public void InitializeComponent() {
        if (_contentLoaded) {
        _contentLoaded = true;
        System.Windows.Application.LoadComponent(this,             new System.Uri("/Hello%20World;component/MainPage.xaml",                            System.UriKind.Relative));
        this.Input = ((System.Windows.Controls.TextBox)(this.FindName("Input")));
        this.Output = ((System.Windows.Controls.TextBlock)(this.FindName("Output")));

We can see where some of the important “glue” is defined. The code derives from UserControl and defines the InitializeComponent method that is called in the constructor.  It also generates the two named controls: Input and Outut based on the names defined in the XAML.  The InitializeComponent method then desterilizes the XAML into an object tree.  It finishes by setting the Input and Output controls to be items found in the visual tree.  This is how the “code-behind” can access these controls in the SayHello method.

The last bit of glue happens in the compiler.  The XAML file is compiled into the DLL as an “embedded resource”.  This happens automatically so you don’t need to think about it.  If you are curious, you can crack open the DLL with Reflecor and find the XAML packed into the DLL.  The InitializeComponent method loads the tree from the same XAML file which is embedded at compile-time.



MXML in Flex is used to define the user interface in a declarative way.  MXML is nothing more than XML with some Flex namespaces that let you represent a visual tree.  Following is an example of Main.mxml.

<?xml version="1.0" encoding="utf-8"?>

<s:Application xmlns:fx=""


              width="300" height="40">



            public function sayHello():void{

                output.text = "Hello "+ input.text;




   <s:BorderContainer borderWeight="5" cornerRadius="5"

                      borderColor="black" minHeight="0" width="100%">

        <s:HGroup left="3" right="3" top="3" bottom="3">

            <s:TextInput width="100" id="input"/>

            <s:Button label="Say Hello" click="sayHello()" left="6"/>

            <s:Label id="output" left="6" verticalAlign="bottom" height="100%"/>




This MXML code defines the entire application.  It is composed of a BorderContainer that houses three UI components grouped together: text input, a button to do something with and a label to show the output.  If you were to type this into your Main.mxml view in Flex, it would look like this in your browser:


Of course, the declarative MXML is nothing without some imperative behavior.  The default way to do this in Flex is to use the HTML model of Script tags.  The sayHello method is defined directly in the MXML.  There are better ways (in my opinion) to separate the imperative behavior from the view, but this is a simple example.

Most MXML introductions get off the train at this point.  This series aims to show the differences between Silverlight and Flex, so I will continue to describe what happens to this MXML at compile-time.

Unlike Silverlight where the XAML is embedded in the compiled project and parsed at runtime, Flex takes a different approach.  MXML views get parsed at compile-time and translated directly into ActionScript. The actual code that the compiler generates is transient – it gets removed after the compile step — unless you add the –keep-generated-actionscript flag to the compiler.

When this happens, quite a lot of code gets generated.  I don’t want to put everything on this post, but here is a snippet from the generated code:

public class Main extends spark.components.Application   

    [Bindable] public var input : spark.components.TextInput;   
    [Bindable] public var output : spark.components.Label;

    public function Main()



        this.width = 300;

        this.height = 40;

        this.mxmlContentFactory = new mx.core.DeferredInstanceFromFunction(_Main_Array1_c);



The constructor sets up a _Main_Array1_c function which calls several other methods hierarchically which creates the controls that were defined in the MXML.

The details of the generated code are not terribly important.  The important thing to understand is that the MXML gets compiled into ActionScript and it is not parsed at run-time.  XAML in Silverlight gets parsed at run-time but VisualStudio does generate some C# code to help glue the XAML to the code-behind.

Tags: , , , ,

5 Responses to “Cross-Training in Silverlight and Flex – XAML vs MXML”

  1. Cross-Training in Silverlight and Flex – XAML vs MXML…

    Thank you for submitting this cool story – Trackback from DotNetShoutout…

  2. [...] This post was mentioned on Twitter by Brian Genisio, Michael Crump [MCPD]. Michael Crump [MCPD] said: Very interesting article. RT @BrianGenisio: Blogged: Cross-Training in #Silverlight and #Flex — XAML vs MXML #fb [...]

  1. Mike Brown says:

    Good summary of the similarities between the two platforms (as an aside, the Android platform also has a declarative, xml-based UI). I had noticed the similarity between the two as well.

    One quick nitpick though. XAML is compiled into a binary format called BAML which is more efficient to interpret at runtime than the Raw XML. Looking forward to future posts in your series.

Leave a Reply