-----Original Message-----
From: James, Roshan
Sent: Tuesday, December 09, 2003 11:57 PM
 Subject: XAML and markups: Introducing WFML - WinForms Markup Language

Hi Folk,

Ever since Linux Bangalore I have been thinking about something that Miguel de Icaza had demoed on stage. He was showing Mono’s UI, Glade, and showed how Glade generates UI from XML markup. They (Miguel and Nat) were also joking as to how XAML is an idea that they had thought of 6 years back – the idea of using XML markup for representing UI and separating 'business logic' from UI.

            He also went on to show how Glade is used to generate GTK# UI in linux. A '.glade' file is simply an xml file that contains tags that correspond to the properties of the controls (or widgets as they call them).

(I pulled glade file off the net to give you an idea of what it looks like

< widget class="GtkWindow" id="window2">

  < property name="visible">True< /property>

  < property name="title" translatable="yes">window2< /property>

  < property name="type">GTK_WINDOW_TOPLEVEL< /property>

  < property name="window_position">GTK_WIN_POS_NONE< /property>

  < property name="modal">False< /property>

  < property name="resizable">True< /property>

  < property name="destroy_with_parent">False< /property>

  < child>

    < widget class="GtkButton" id="button1">

      < property name="border_width">10< /property>

      < property name="visible">True< /property>

      < property name="can_focus">True< /property>

      < property name="label" translatable="yes">button1< /property>

      < property name="use_underline">True

      < property name="relief">GTK_RELIEF_NORMAL< /property>

    < /widget>

  < /child>

< /widget>

)

The strange thing was how they used glade files - in XAML you compile the xml file to generate a class (or what MS calls a partial class, one that can be extended elsewhere). In glade they did no such thing, they simple wrote a cs file and called one Glade API function passing it the name of '.glade' file. That returned some kind of object and presto they had their UI. Now the claim was that this really separates the UI from the code and as a matter of fact the XML can be chnaged after the exe file has been compiled. Changes to the XML will reflect in the UI without recompilation of anything. They also mentioned that Microsoft hasn’t figured out how to do this yet.

(Here is fragment of c# code that uses the .glade

                using Gtk;

                using Gnome;

                using Glade;

                using GtkSharp;

        public class GladeTest

                {

                                /* If you want to access the glade objects you have to "import" them.

                                 * This is not required, but else you can only work with the

                                 * pre-defined signal handlers */

                                [Glade.Widget]     

                                Button button1;

                                public GladeTest (string[] args)

                                {

                                                Application.Init();

                                                /* This loads the glade file glade.glade,

                                                 * selects window2 and connects it to the current object,

                                                 * which is the class GladeTest here. */

                                                Glade.XML gxml = new Glade.XML ("file.glade", "window2", null);

                                                gxml.Autoconnect (this);

                                                button1.BorderWidth=10;

                                                Application.Run();

                                }

)

            Now this got me thinking about how they implemented this dynamic behavior - as result of which WFML was born. It was rather surprising how easy this was to do. I am sure Miggy's code will be better and more optimized, but I think my general direction is correct.

WFML, in short provides (or at least hopes to provide) a markup language for UI that simply does not have to compiled (in the conventional sense). WFML UI is actually WinForms based UI, WFML by itself cannot add any features that are not present in WinForms. What it does is that it lets you write very clean looking code that does not have a clutter for UI itself. The entire UI of the program is expressed in an external XML file, called a .wfml file. Now if you have ever tried writing a Win forms application by hand without studio, you will remember how hard it is to remember so many of the house-keeping things required - take a look at some WFML based code:

//win.cs

using System;

using System.Windows.Forms;

using System.Windows.Forms.Markup;

class CMain

{

        static void Main()

        {

                IAttachable win = new Wfml().CreateUserInterface("win.wfml","MainWindow");

                Application.Run((Form)win);

        }

}

Simple ? This is a C# file that uses the WFML library. The markup lib being a pure .Net assembly can be used by any .Net language, - C#, VB, C++, Jscript, VJ# etc. Now what you need is a WFML file that specifies the UI. And you simply write the .wfml file like this (win.wfml):

        < Window

                Name="MainWindow"

                Height="200"

                Width="400"

        />

As you can see, the WFML is simply an XML file with certain tags that the WFML library understands. The advantage of using something like WFML is that you can completely change this XML at will and the UI of your program can be completely changed.

Now compile the cs:

csc /t:winexe /r:System.Windows.Forms.Markup.dll win.cs

Run win.exe and you will see an empty window

The following .wfml code displays a button and a text box for the same win.exe program. The program need not be edited or recompiled, only the .wfml file needs to be changed.

< Window

        Name="MainWindow"

        Height="200"

        Width="400"

        Text="Main Window"

>

        < Button Name="mybutton"

                Top="10"

                Text="Click Me"

        />

        < TextBox

                Name="tbox"

                Top="40"

                Left="5"

                Width="200"

        />

(What tags and attributes are allowed within a WFML? Every attribute that you set in a tag has to be a property of the corresponding WinForms type. That is to say that if you want to put a attribute called ‘Text’ in the ‘Window’ tag, then the class System.Windows.Form.Window should support a property called Text. WFML being a very simple system is case sensitive and provides no error feedback if something is wrong.)

And you can even attach event handlers and write back to the UI:

using System.Windows.Forms;

using System.Windows.Forms.Markup;

using System;

class CMain

{

        public TextBox tbox;

        public void clicked(object sender, EventArgs e)

        {

                tbox.Text+="+ ";

        }

        static void Main()

        {

                IAttachable win = new Wfml().CreateUserInterface("win.wfml","MainWindow");

                CMain cm = new CMain();

                win.AttachConsumer(cm);

                Application.Run((Form)win);

        }

}

Do try some WFML, the supported types are Button, TextBox and Label - but I guess the rest can be added easily.  Now I don't think this was anywhere as hard as they were making it out to be on stage.

Roshan James

------------------------------

You can download the WFML.zip file here. This also contains the demos that I had for this UG post.  While I never did continue on the WFML, folk did mail me back asking about the WFML assuming it was part of a larger UI framework.

Of course, capital negatives of the approach are that there is no IDE to ease development of WFML and such, but the idea itself is rather interesting.

How WFML actually works, as you might have guess is that it uses reflection API to dynamically generate a System.Windows.Form type that is customized according to the WFML file. This runtime generated type also runs reflection based code on its caller and appropriately latches up event handlers dynamically. Also it uses reflection to assign references of the caller to classes to the actual objects created in the generated Form class.

You however need not compare XAML to WFML or like approaches because XAML is a whole different beast. Differences start with be67ing vectored based don’t stop any time soon.