How to build types that can be consumed from XAML
Now that you know how to use custom types in XAML, you might be wondering if there are any thing you should keep in mind when designing new types that should be consumed from XAML. I’ve already said before that collection properties need to have a getter that return a valid instance of an object. But there’s more. Here are a few things you should consider when designing types for being consumed from XAML:
- Elements can only be public classes which have a public parameterless constructor (notice that nested classes aren’t supported);
- structs are usable from XAML too (consider using a type converter in some scenarios where you don’t want to use the default constructor to initialize the struct)
- non-collections properties which reference objects (ie, not primitive types) should ensure that the type has a default constructor (or that the type or property that is being defined has an adequate type converter);
- you should use type converters when you’re using a reference type which does not have a default constructor (or when you’ve used an abstract type as the type of a property).
Regarding collections, you’ve already seen the requisites for using them from XAML: the type should implement the IList or the IDictionary/IDictionary<TKey, TValue> interfaces.
And I guess this sums it up quite nicely. Stay tuned for more on Silverlight.