[XML Records] XmlToRecordList with i:nil="true" attribute makes the library return error

Forge Component
(44)
Published on 2019-11-25 by Afonso Carvalho
44 votes
Published on 2019-11-25 by Afonso Carvalho

Hi Afonso, really useful library!


Has anybody tried with i:nil="true" attributes? Down is one of my xml structures, containing such attributes. 

I have tried XmlToRecordList with manually removing the i:nil="true" attribute and it worked well, but it returns an Error, when I try with them. Maybe it is not implemented in the library yet?

Cheers!


<?xml version="1.0" encoding="UTF-8"?>

<ArrayOfAssemblyUsage xmlns="http://schemas.datacontract.org/2004/07/o2Smart.DocumentAssembly.Web.WebObjects" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">

   <AssemblyUsage>

      <AssembledFiles>

         <AssembledFile>

            <DateCreated>2018-07-09T07:07:52.1332163Z</DateCreated>

            <DownloadLink>http://localhost:56052/Integration/Download.aspx?fileIdentifier=a04a0447-bda2-4ea7-93bb-438a10ed333f</DownloadLink>

            <FilePath>Documents\FaxCoverExample.3.docx</FilePath>

            <FileSize>13 KB</FileSize>

            <FileType>MS Word 2007</FileType>

            <Identifier>a04a0447-bda2-4ea7-93bb-438a10ed333f</Identifier>

            <ServerFile>

               <DateUploaded>2018-07-09T07:07:52.1332163Z</DateUploaded>

               <Description i:nil="true" />

               <FileSize>13 KB</FileSize>

               <FileType>MS Word 2007</FileType>

               <Identifier>TY8age3/tOHSXIS2MqB22SA8JGYTczrCck1K9RKaKnNxZ+csCpbmtA==</Identifier>

               <Name>FaxCoverExample.3.docx</Name>

               <TemplateIdentifier i:nil="true" />

               <URL>http://localhost:56052/Protected/Download.aspx?fileIdentifier=TY8age3%2ftOHSXIS2MqB22SA8JGYTczrCck1K9RKaKnNxZ%2bcsCpbmtA%3d%3d</URL>

            </ServerFile>

         </AssembledFile>

      </AssembledFiles>

      <DataDownloadLink>http://localhost:56052/Integration/Download.aspx?usageIdentifier=0b6db589-1b50-47c0-891d-882bc734b23c</DataDownloadLink>

      <DataFileDateCreated>2018-07-09T07:07:52.6265813Z</DataFileDateCreated>

      <DataFilePath>Datasets\FaxCoverExample.3.xddata.xml</DataFilePath>

      <DataFileSize>518 bytes</DataFileSize>

      <DataFileType i:nil="true" />

      <ID>7</ID>

      <Identifier>0b6db589-1b50-47c0-891d-882bc734b23c</Identifier>

      <ReturnURL i:nil="true" />

      <ServerFile>

         <DateUploaded>2018-07-09T07:07:52.6265813Z</DateUploaded>

         <Description i:nil="true" />

         <FileSize>518 bytes</FileSize>

         <FileType>XML File</FileType>

         <Identifier>xapI3smfLMHhqfs84jGM/mg6XyBO48UBck9dOtteLKYSRnWDxf/YSA==</Identifier>

         <Name>FaxCoverExample.3.xddata.xml</Name>

         <TemplateIdentifier i:nil="true" />

         <URL>http://localhost:56052/Protected/Download.aspx?fileIdentifier=xapI3smfLMHhqfs84jGM%2fmg6XyBO48UBck9dOtteLKYSRnWDxf%2fYSA%3d%3d</URL>

      </ServerFile>

      <TemplateIdentifier>0ec756a0-9c65-4307-9a57-8634c5505155</TemplateIdentifier>

      <TemplatePath>FaxCoverExample.xdtpx</TemplatePath>

   </AssemblyUsage>

</ArrayOfAssemblyUsage>


Hi Borislav,

Thank you - this was an effort by a big team, I'm just one of the latest contributors. 

I'm not sure why a specific attribute would cause an error. I don't believe specific attributes receive special treatment, so in theory they should all be the same. I'm going to look into this, but it might take me some time. There's a couple of things you could help me with in the meantime:

 - Can you confirm that you're using the latest version of the extension? The first bug I fixed a couple of years back was related to XML attributes not being processed correctly, though they didn't return errors.

 - What is the exact error you're receiving? Could you show us a stack trace from Service Center?

 - Could you share a module with an example of your XmlToRecordList usage? It doesn't have to be your entire application, I understand you might have proprietary code in it - just a module with the Structures you use for your XML already created would speed up the process tremendously.

Hello Afonso,

yes, I do use the latest version.

Btw I am also struggling to create a working XmlToRecordList serialization for this structure, as well:


<string xmlns="http://schemas.microsoft.com/2003/10/Serialization/">3c6211f4-d907-489b-aba4-ee335c31f694</string>


I am using this structure: 


I get the following error: 

"Sequence contains no matching element"


As for the previous problem, I currently don't have an example, since I deleted it back then and made a manual traversal instead. I can notify you, if I built one again. But as for debugging, maybe you can just try manually plugging  i:nil="true" for some of your existing attributes, as in the example above:


  <Description i:nil="true" /> 

 and I am sure you will get the error, which I got earlier.


P.S. I haven't used any configurations whatsoever, but I saw "ExcludeIfNull" in "DefaultXmlConfig". However, I saw also, that the default value is "True", so I don't expect it to make any difference.

Solution

Here's an example for your string XML. You can see it catching both the string value and the xmlns attribute in debug - let me know if this makes it clearer. I will try and make a test case for the i:nil attribute.

Solution

Afonso Carvalho wrote:

Here's an example for your string XML. You can see it catching both the string value and the xmlns attribute in debug - let me know if this makes it clearer. I will try and make a test case for the i:nil attribute.

 Hey Afonso,


thanks a lot! It works that way. I didn't know I have to do it so with this attribute. I couldn't find a good documentation of the cases for XmlToRecordList's usage, unlike the better documented RecordListToXml.


And btw I found what the problem with the i:nil="true" issue seems to be. This is the type of error, that appears:

I tracked the problem to lie in the :symbol  as the code proceeds normally, when removed from the name. 

I wasn't able to localize the exact place in the extension code, where this happens, but probably it could be solved by simple escaping on the proper place. What do you think?

I believe the issue is that namespaces need to be identified. It's not something I've used very often, but I know there's an attribute in the XmlConfig structure that lets you identify them - I'll try to create an example.

Thank you for the feedback on the XmlToRecordList documentation. I will give it a read and improve on it.

Webscreen2 has an example of configuration for attributes. There might be a better way to recognize namespaces, but you can definitely do it with the AttributesConfig input.