It is certanly possible to load different UI controls into a window at run-time. AVPad does this now to a degree. The real issue is going to be hooking the UI up to the code behind class(es). Loading XAML at runtime will not benifit from the event delegate generation and element naming that exist in the compiled code/BAML combination. If the XAML loader parses all properties and retains those as properties at run-time you could do a pass on the parse tree to hook these things up at run-time. I expect to see many applications offering this type of pluggable UI model as Avalon sinks into the developer community. --Michael
Essentially what is being implied here is that you can load up XAML at runtime but you will have to re-hook up the properties and the events at run-time because the loader. However, I have been thinking that getting the people who change the UI to create BAML is not all of a problem really. Therefore the app will be able to load a new compiled XAML file and use the same UI class on the backend.
An example might be we design two layouts each different from each other however they both share the same code-behind class:
<window class="AvalonApplication1.Window1" xmlns="http://schemas.microsoft.com/winfx/avalon/2005" x="http://schemas.microsoft.com/winfx/xaml/2005" text="AvalonApplication1"><window class="AvalonApplication1.Window1" xmlns="http://schemas.microsoft.com/winfx/avalon/2005" x="http://schemas.microsoft.com/winfx/xaml/2005" text="AvalonApplication2">
This might work, I haven't tried it yet.
I am looking into loading a XAML file that simply contains resources at runtime and then assigning them also at runtime. I will let you know of the results.