Xml failing to deserialise
- by Carnotaurus
I call a method to get my pages [see GetPages(String xmlFullFilePath)]. The FromXElement method is supposed to deserialise the LitePropertyData elements to strongly type LitePropertyData objects. Instead it fails on the following line:
return (T)xmlSerializer.Deserialize(memoryStream);
and gives the following error:
<LitePropertyData xmlns=''> was not expected.
What am I doing wrong? I have included the methods that I call and the xml data:
public static T FromXElement<T>(this XElement xElement)
{
using (var memoryStream = new MemoryStream(Encoding.ASCII.GetBytes(xElement.ToString())))
{
var xmlSerializer = new XmlSerializer(typeof(T));
return (T)xmlSerializer.Deserialize(memoryStream);
}
}
public static List<LitePageData> GetPages(String xmlFullFilePath)
{
XDocument document = XDocument.Load(xmlFullFilePath);
List<LitePageData> results = (from record in document.Descendants("row")
select new LitePageData
{
Guid = IsValid(record, "Guid") ?
record.Element("Guid").Value :
null,
ParentID = IsValid(record, "ParentID") ?
Convert.ToInt32(record.Element("ParentID").Value) :
(Int32?)null,
Created = Convert.ToDateTime(record.Element("Created").Value),
Changed = Convert.ToDateTime(record.Element("Changed").Value),
Name = record.Element("Name").Value,
ID = Convert.ToInt32(record.Element("ID").Value),
LitePageTypeID = IsValid(record, "ParentID") ?
Convert.ToInt32(record.Element("ParentID").Value) :
(Int32?)null,
Html = record.Element("Html").Value,
FriendlyName = record.Element("FriendlyName").Value,
Properties = record.Element("Properties") != null ? record.Element("Properties").Element("LitePropertyData").FromXElement<List<LitePropertyData>>() :
new List<LitePropertyData>()
}).ToList();
return results;
}
Here is the xml:
<?xml version="1.0" encoding="utf-8"?> <root> <rows>
<row>
<ID>1</ID>
<ImageUrl></ImageUrl>
<Html>Home page</Html>
<Created>01-01-2012</Created>
<Changed>01-01-2012</Changed>
<Name>Home page</Name>
<FriendlyName>home-page</FriendlyName>
</row>
<row xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Guid>edeaf468-f490-4271-bf4d-be145bc6a1fd</Guid>
<ID>8</ID>
<Name>Unused</Name>
<ParentID>1</ParentID>
<Created>2006-03-25T10:57:17</Created>
<Changed>2012-07-17T12:24:30.0984747+01:00</Changed>
<ChangedBy />
<LitePageTypeID xsi:nil="true" />
<Html>
What is the purpose of this option? This option checks the current document for accessibility issues. It uses Bobby to provide details of whether the current web page conforms to W3C's WCAG criteria for web content accessibility.
Issues with Bobby and Cynthia
Bobby and Cynthia are free services that supposedly allow a user to expose web page accessibility barriers. It is something of a guide but perhaps a blunt instrument. I tested a few of the webpages that I have designed. Sure enough, my pages fall short and for good reason. I am not about to claim that Bobby and Cynthia are useless. Although it is useful and commendable tool, it project appears to be overly ambitious. Nevertheless, let me explain my issues with Bobby and Cynthia:
First, certain W3C standards for designing web documents are often too strict and unworkable. For instance, in some versions W3C standards for HTML, certain tags should not include a particular attribute, whereas in others they are requisite if the document is to be ???well-formed???. The standard that a designer chooses is determined usually by the requirements specification document. This specifies which browsers and versions of those browsers that the web page is expected to correctly display. Forcing a hypertext document to conform strictly to a specific W3C standard for HTML is often no simple task. In the worst case, it cannot conform without losing some aesthetics or accessibility functionality.
Second, the case of HTML documents is not an isolated case. Standards for XML, XSL, JavaScript, VBScript, are analogous. Therefore, you might imagine the problems when you begin to combine these languages and formats in an HTML document.
Third, there is always more than one way to skin a cat. For example, Bobby and Cynthia may flag those IMG tags that do not contain a TITLE attribute. There might be good reason that a web developer chooses not to include the title attribute. The title attribute has a limited numbers of characters and does not support carriage returns. This is a major defect in the design of this tag. In fact, before the TITLE attribute was supported, there was the ALT attribute. Most browsers support both, yet they both perform a similar function. However, both attributes share the same deficiencies. In practice, there are instances where neither attribute would be used. Instead, for example, the developer would write some JavaScript or VBScript to circumvent these deficiencies. The concern is that Bobby and Cynthia would not notice this because it does not ???understand??? what the JavaScript does.
</Html>
<FriendlyName>unused</FriendlyName>
<IsDeleted>false</IsDeleted>
<Properties>
<LitePropertyData>
<Description>Image for the page</Description>
<DisplayEditUI>true</DisplayEditUI>
<OwnerTab>1</OwnerTab>
<DisplayName>Image Url</DisplayName>
<FieldOrder>1</FieldOrder>
<IsRequired>false</IsRequired>
<Name>ImageUrl</Name>
<IsModified>false</IsModified>
<ParentPageID>3</ParentPageID>
<Type>String</Type>
<Value xsi:type="xsd:string">smarter.jpg</Value>
</LitePropertyData>
<LitePropertyData>
<Description>WebItemApplicationEnum</Description>
<DisplayEditUI>true</DisplayEditUI>
<OwnerTab>1</OwnerTab>
<DisplayName>WebItemApplicationEnum</DisplayName>
<FieldOrder>1</FieldOrder>
<IsRequired>false</IsRequired>
<Name>WebItemApplicationEnum</Name>
<IsModified>false</IsModified>
<ParentPageID>3</ParentPageID>
<Type>Number</Type>
<Value xsi:type="xsd:string">1</Value>
</LitePropertyData>
</Properties>
<Seo>
<Author>Phil Carney</Author>
<Classification />
<Copyright>Carnotaurus</Copyright>
<Description>
What is the purpose of this option? This option checks the current document for accessibility issues. It uses Bobby to provide details of whether the current web page conforms to W3C's WCAG criteria for web content accessibility.
Issues with Bobby and Cynthia
Bobby and Cynthia are free services that supposedly allow a user to expose web page accessibility barriers. It is something of a guide but perhaps a blunt instrument. I tested a few of the webpages that I have designed. Sure enough, my pages fall short and for good reason. I am not about to claim that Bobby and Cynthia are useless. Although it is useful and commendable tool, it project appears to be overly ambitious. Nevertheless, let me explain my issues with Bobby and Cynthia:
First, certain W3C standards for designing web documents are often too strict and unworkable. For instance, in some versions W3C standards for HTML, certain tags should not include a particular attribute, whereas in others they are requisite if the document is to be ???well-formed???. The standard that a designer chooses is determined usually by the requirements specification document. This specifies which browsers and versions of those browsers that the web page is expected to correctly display. Forcing a hypertext document to conform strictly to a specific W3C standard for HTML is often no simple task. In the worst case, it cannot conform without losing some aesthetics or accessibility functionality.
Second, the case of HTML documents is not an isolated case. Standards for XML, XSL, JavaScript, VBScript, are analogous. Therefore, you might imagine the problems when you begin to combine these languages and formats in an HTML document.
Third, there is always more than one way to skin a cat. For example, Bobby and Cynthia may flag those IMG tags that do not contain a TITLE attribute. There might be good reason that a web developer chooses not to include the title attribute. The title attribute has a limited numbers of characters and does not support carriage returns. This is a major defect in the design of this tag. In fact, before the TITLE attribute was supported, there was the ALT attribute. Most browsers support both, yet they both perform a similar function. However, both attributes share the same deficiencies. In practice, there are instances where neither attribute would be used. Instead, for example, the developer would write some JavaScript or VBScript to circumvent these deficiencies. The concern is that Bobby and Cynthia would not notice this because it does not ???understand??? what the JavaScript does.
</Description>
<Keywords>unused</Keywords>
<Title>unused</Title>
</Seo>
</row> </rows> </root>
EDIT
Here are my entities:
public class LitePropertyData
{
public virtual string Description { get; set; }
public virtual bool DisplayEditUI { get; set; }
public int OwnerTab { get; set; }
public virtual string DisplayName { get; set; }
public int FieldOrder { get; set; }
public bool IsRequired { get; set; }
public string Name { get; set; }
public virtual bool IsModified { get; set; }
public virtual int ParentPageID { get; set; }
public LiteDataType Type { get; set; }
public object Value { get; set; }
}
[Serializable]
public class LitePageData
{
public String Guid { get; set; }
public Int32 ID { get; set; }
public String Name { get; set; }
public Int32? ParentID { get; set; }
public DateTime Created { get; set; }
public String CreatedBy { get; set; }
public DateTime Changed { get; set; }
public String ChangedBy { get; set; }
public Int32? LitePageTypeID { get; set; }
public String Html { get; set; }
public String FriendlyName { get; set; }
public Boolean IsDeleted { get; set; }
public List<LitePropertyData> Properties { get; set; }
public LiteSeoPageData Seo { get; set; }
/// <summary>
/// Saves the specified XML full file path.
/// </summary>
/// <param name="xmlFullFilePath">The XML full file path.</param>
public void Save(String xmlFullFilePath)
{
XDocument doc = XDocument.Load(xmlFullFilePath);
XElement demoNode = this.ToXElement<LitePageData>();
demoNode.Name = "row";
doc.Descendants("rows").Single().Add(demoNode);
doc.Save(xmlFullFilePath);
}
}
