A Visual Studio 2008 Solution with the complete code listing for this series is attached to the final part.
The XAML framework allows us to easily switch between the Declarative and Imperative programming models easily. Examples such as event handlers are obvious cases where this happens, while others, such as MarkupExtensions and ValueConverters for Bindings are not so clear - when you implement the ProvideValue method of a custom MarkupExtension, you are suddenly in the the imperative world of C# (or CLR language of your choice) where as the XAML document that declared the MarkupExtension is declarative in nature.
The ability to dynamically load XAML using the XamlParser class allows the programmer to switch in and out of the declarative and imperative worlds with ease, affording them great power and flexibility. Or so it would seem...
Dynamically loaded XAML does not integrate with the imperative world as well as it's compiled brethren. For example, you completely lose the ability to route events to handlers when loading XAML dynamically. This greatly hampers the usefulness of dynamically loaded XAML. The stance in the community is that you should simply compile your XAML if you want to handle events. In many instances this is just not an acceptable solution!
There are a number of interpreted (hence dynamic) imperative languages that bind to the CLR, such as Python and Ruby. The new Dynamic Language Runtime (DLR) will encourage the development off new dynamic languages as well as the binding of existing dynamic languages to .NET. In this series of 6 articles I will demonstrate how to embed any and all DLR languages in XAML.