/// <summary>
/// Check an XmlElement to see if it includes a specific "Type" attribute. If so, return
/// the actual Type associated with that attribute's value.
/// </summary>
/// <param name="_xml">The XmlElement containing the field's information</param>
/// <param name="_defaultType">
/// If there is no Type attribute, then return this value as the "default"
/// </param>
/// <returns>
/// NULL if no Type attribute was found, or the Type object corresponding the value of
/// the Type attribute
/// </returns>
/// <exception cref="InvalidOperationException">
/// Thrown if there is a Type attribute, but that attribute's value cannot be turned
/// into a Type object.
/// </exception>
private Type GetTypeFromXmlOrDefault(XmlElement _xml, Type _defaultType)
{
var sType = XmlExtensions.GetAttributeValue(_xml, m_context.TypeAttributeName);
if (sType == null) // There is no explicit Type specifier (XmlAttribute)
{
return(_defaultType);
}
var explicitType = Lib.BetterGetType(sType, true);
if (explicitType == null)
{
// The XML had an explicit Type, but that Type couldn't be found. So... If we
// are trying to deserialize a Type that uses EntitySemantics, we assume that
// the destination Type is sufficient to figure out what to deserialize. If the
// destination Type is wholly inadequate to "receive" the data in the XML, the
// application is at fault. For Entities, this type of mismatch is OK.
if (CEntityTypeData.UsesEntitySemantics(_defaultType))
{
return(_defaultType);
}
// However, if this isn't using EntitySemantics, then throw an exception as the
// Type is unknown.
throw new XDeserializationError("An Attribute was found for an Explicit Type, but it could not be turned into a Type: " + sType);
}
return(explicitType);
}
