Charles Petzold asks if we are deliberately or accidentally making code-based scenarios difficult. He sums it up well with the title of the piece: "XAML Rules (but Code Suffers)".
Thanks Charles for raising this issue. I'll make sure the right dev team sees the feedback.
Please let us know other scenarios that are difficult from code. We haven't found them all, but want to hear...many of these decisions are not deliberate.
We still have some constructs that the XAML parser uses that don't help us make sure we build well designed objects.
As I said back in October 2004:
For a long time, we've relied on IAddChild and let component authors decide what their ContentProperty was. We're hoping to decorate types with that information and remove IAddChild from Avalon.
We are now finally in the middle of trying to do that change. We are making the parser stop calling IAddChild. An example of fixes that we need to do to help make this possible:
- Make Grid stop supporting RowDefinition/ColumnDefinition as direct children of Grid.
- Make sure we decorate the appropriate ContentPropertyAttribute for all classes. For example, Panel will have [ContentProperty("Children")]
- Make sure collections support IList. For example, UIElementCollection will get an IList mechanism.
So instead of having IAddChild implemented on Panel, we added the ContentProperty attribute to that class. We then make sure the collection that is returned by that property supports IList.
We are finding and fixing a bunch of issues including incompletely designed classes where problems where hidden by the reliance on IAddChild...
In the public builds you may not be able to wean yourself from IAddChild yet...perhaps due to blocking bugs...but you should try. I'll eventually publish more details in this area...let me know if you are blocked by any lack of info here...