Disclaimer: This technology does not actually exist yet, I am looking for feedback about this idea and anyone interested in working on it.
I’m sure a lot of you have seen this image. It highlights some of the pain of working with Silverlight coming from a WPF background.
It occurred to me over the weekend that this is really a statement about the consistency of the implementation of XAML DOM APIs. With that in mind the next logical conclusion was that there is a very important parallel in the Javascript world, i.e. the consistency of the implementation of the Javascript and HTML DOM APIs. Thankfully since about 2005, much of this pain has been encapsulated into jQuery.
So what about XAML? What can we do about it? This is where XamQuery would come in. Here’s a highlight of the core features I see and where I have needed them:
A XAML DOM selector engine similar to Sizzle. Given that XAML doesn’t have complex selector syntax like CSS this would essentially be a highly optimized tree walker for the VisualTree that would wrap the disjoint APIs in WPF / Silverlight for getting visual parents and children.
A set of fluent APIs for creating XAML DOM objects (Panels, Controls, etc) that would wrap some annoying inconsistencies when travelling between Silverlight and WPF as well as making it easier to do things in code that are painfully verbose in pure XAML (I think states of the VSM is a great example of this).
A simple plug-in system for System.Interactivity Attached Behaviors to attach into. This would mirror the jQuery plugin system where each selector statement actually returns the jQuery object which you can then call plugins on.
Feel free to contact me directly about this idea. I’m looking to get some like minded developers together to work on this. I think that this could be the thing that takes WPF and Silverlight development to the next level.