I was browsing through Paul Stovell’s blog recently and found that we had some eerily similar concepts around WPF that we had independently … ummm … conceptualized. One of the strangest coincidences was our almost simultaneous (yet again independent) formation of a Domain Tree concept. Basically the idea is that like the Visual Tree in WPF uses DependencyProperties to provide a bunch of neat features, an application can use a Domain Tree that provides inheritable properties (like CurrentUser and Permissions) to child nodes within the tree. The nodes can even override the properties for themselves and their children. Although, I don’t have proof that I developed this concept simultaneously and independently (I did have some conversations with co-workers about it prior to Paul’s post being made).
Anyway, I really got to thinking about it when I realized that a WPF Dependency Property and a WF Dependency Property are totally separate beasts! Their only common ancestor is Object. So even though WPF and WF have very similar concepts, they are different enough to merit their own implementation of those concepts. Why aren’t DependencyProperty and DependencyObject members of the System namespace? Or at least DependencyPropertyBase and DependencyObjectBase? What implications does this have for a Domain Tree?
If I were to pursue implementing a Domain Tree, would it make sense to implement my own Dependency mechanisms so that it isn’t tied to WPF? After all, there is nothing that prevents WPF from binding to a property that isn’t a System.Windows.DependencyProperty.
What would the Domain Tree have to provide to make it useful? Could someone declare their App Domain fully in XAML? For that to be useful we’d need a designer that supports it. Maybe something based off of the DSL tools.
It’s funny, I had some notes a long time ago about using XML to program an application. Let’s call it Windows Application Foundation. This is gonna be fun!!