XamlMember Class

XamlMember defines several virtual members that derived classes might override. These members have names that always start with the string Lookup. The remainder of the API name then references the property that the virtual method influences. For example, a XamlMember derived class might override LookupTargetType to influence what the base-defined property TargetType returns in a derived class. You can predict return values for such properties in XamlMember or existing derived classes by reading the documentation for the relevant Lookup* methods.

The purpose of the Lookup* methods is to provide a XAML type system extension technique that incorporates the XamlMember base class. By deriving from XamlMember and overriding the Lookup virtual members, you can define the concept of a XAML member for a XAML schema in a XAML type system without being tied to the specifics of a backing type system or technology. You can also use a provided XAML schema context under this scheme and still return the results you want.

As an example, consider the XamlMember property IsWritePublic. This property informs callers that operations such as using a XamlWriter for serialization can write a value for this member on a target object. In the default implementation, the determination of whether the member is writable is made by using reflection techniques against the backing CLR Type and its members (the MemberInfo). Therefore, by default, the XAML type system depends on the CLR type system. However, you can remove this dependency for your XAML type system reporting of IsWritePublic by overriding the API LookupIsWritePublic. Within your override, you can use other determinations, such as metadata that is specific to your technology, a master lookup table that is optimized for a fixed XAML vocabulary, or a variety of other strategies for determining whether a XAML member is writable in your XAML vocabulary.

Most constructors of XamlMember require a XamlSchemaContext as part of their initialization. The XamlSchemaContext is also necessary for many internal XamlSchemaContext operations, such as obtaining information that is being forwarded from the backing type. When you are working with the XamlMember API, you typically have a XamlSchemaContext that is available from a surrounding construct such as a XamlWriter. In this case, you can pass the XamlSchemaContext reference through to all XAML type system calls that require a XAML schema context.

One specific constructor, XamlMember(String, XamlType, Boolean), does not require a XamlSchemaContext. However, a XamlMember that is constructed with the XamlMember(String, XamlType, Boolean) signature returns true for IsUnknown.

For a load path that involves XamlObjectWriter, such a member cannot be written into an object graph. Using the .NET Framework XAML services implementation, the XamlObjectWriter.WriteStartMember call throws a XamlObjectWriterException when the relevant XamlMember reports true for IsUnknown.

You should not construct a XamlMember that has a value of true for IsUnknown unless your implementation can handle the exceptions from XamlObjectWriter, or you have other ways to adjust the XamlObjectWriter behavior. For example, one or more of the following might be true of your implementation:

• The XAML schema context is available later.

• You use a member invoker pattern.

• You deliberately override XamlObjectWriter.WriteStartMember in a custom XAML writer.