Rob Relyea

xaml:Blog

Does WPF focus too much on markup scenarios?

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:

  1. Make Grid stop supporting RowDefinition/ColumnDefinition as direct children of Grid.
  2. Make sure we decorate the appropriate ContentPropertyAttribute for all classes.  For example, Panel will have [ContentProperty("Children")]
  3. 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...

Posted on Nov 20 2005, 12:14 PM by rrelyea
Filed under: ,
PostTypeIcon
5,671 Views

Comments

  • Kevin Daly said:
    Actually, since I'm *still* seething over the mini-language decision (come on, you expect me to use half a page to define a simple gradient?), I'd amend that to "tools rule, developers suffer (without them)".
    Sigh.
    November 20, 2005 10:34 AM
  • Bunyan said:
    It seems like part of the problem stems from XAML's ignorance of constructors- it only uses the default constructor. This causes the useful constructors to be ignored in favor of the more verbose properties.

    The real problem as I see it is not that the code is too verbose, it's that without constructors and their argument patterns it gives the user no idea what is needed to construct a valid object. Instead, what should be compilation errors are now runtime exceptions. An example is the Condition class with its Binding and Property properties- if both are set then an exception is thrown.
    November 20, 2005 12:37 PM
  • davidacoder said:
    I agree with the constructor point. I have shown one possible solution (very much like what XLinq does) here:

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=142091&SiteID=1

    I feel pretty strongly that it is important to have ONE object tree creation model for .Net, which spans XML, Avalon etc. Please, have Brad Abrams look at this and then just decide which is the right way to go ;)

    I am not 100% convinced that the way XLinq does it is great, since they loose quite a bit of type checking at compile time with their approach... But still, this should be looked at together.
    November 21, 2005 7:16 AM
  • rrelyea said:
    Kevin-
    Sorry to hear the reduction of mini-languages upset you.

    Bunyan-
    Using anything but the default constructor from markup is problematic once we consider being able to not just load xaml, but to save it as well.
    Yes, we still have a while to go making sure we catch problems at compile time.
    In V1, we are going to be relying more on the fact that xaml designers and xaml editors will create good xaml.
    We don't have time to do the many things necessary that would improve the compile error experience significantly for v1.

    David-
    Yes, we are working with the XLinq team and are considering the impact of XLinq on WPF design. Good suggestion.

    Thanks,
    Rob
    November 22, 2005 6:45 AM