What is Markup Programming

In one sentence, markup programming is the capability in XAML to execute one or more operations under specified conditions. In the broader sense it is everything that that a programming language is: syntax, semantics, techniques to accomplish desired programming goals. A programmer who begins using markup programming is already a seasoned programming because XAML itself is sophisticated programming language of a different kind and markup programming's role is exclusively in the service of XAML.

Traditionally, programming support for XAML has been in the form of C# or Visual Basic and indeed these languages are ideally suited for many of the associated tasks that confront application developers. Whether the task is a view-model, database, service, data structure or algorithm, these workhorse languages will continue to be the mainstay for developers for many years to come.

However XAML presents an opportunity for a partner language that meets XAML on its own terms in the areas of data binding and dynamic objects, understands and addresses the fundamental of its world, data and events, and literally lives in the same textual space as part of the XAML itself. Markup programming intends to be that language.

What Kind of Problems Can Markup Programming Solve

Markup programming is a programming language so it is meant to solve programmer's problems. As briefly as possible, markup programming allows programmers to generate data that is easily consumable by XAML and to write the "glue" that ties events and data together. Another way to describe the problems markup programming can solve is to describe problems that are hard to solve without it. Traditionally in XAML all interactivity was done through code-behind and yet modern methods have found a number of disadvantages with this approach. Markup programming doesn't use any code-behind and so markup that uses it can be stored in resources or processed as loose XAML. Another problem with trying to interoperate with XAML from traditional languages is how awkward the programming is. Data binding, name resolution, templates, etc. that are so clean and readable on the XAML side are complete mess in C#. Finally there is an unavoidable separation of the "what" and the "why" because the code can never be located in the place that it applies to. But the truth is that with a complete programming language at your disposal, you can do practically anything. It can be used, misused, absued or not used at all.

Where Should I Start?

A good strategy would be to take a small program and rewrite it so that it doesn't use any code-behind. When the code-behind file is empty except for the constructor, you can delete the MainPage.xaml.cs file and it will still compile and run! It doesn't mean you should have any code. Of course you may have classes for your view-model or for converters or custom controls, etc. The goal of the exercise is just to remove the code-behind file. This exercise will show you that most event handlers in your code-behind file are intimately related to the page itself anyway and the function they perform looks perfectly at home in the XAML instead of in the code-behind. Furthermore, doing so will give you a good feel for the meat-and-potatoes of simple events in markup programming to let you know if love it or hate it. Good luck and hopefully you'll find enough to like to try out some of the advanced features.


Last edited Mar 31, 2011 at 6:15 AM by jrs, version 8


No comments yet.