soap encoded arrays in 0.3.8 - suds - Fedora mailing-lists

24 Nov 2009


      All,
Hopefully, this is good news :)
Revision 607 completes unmarshaller side of the 'enhanced soap (section 5) encoded arrays' 
feature in 0.3.8.  What this does is flatten the soap encoded arrays in rpc/encoded 
services into python lists.  Remember, soap encoded arrays are Array objects which contain 
a collection of xs:any/.  So, for an array of (int), the XML would look like this:
<foo>
   <numbers xsi:type="soap-enc:Array" soap-enc:arrayType="xs:int[2]">
     <number>1</number>
     <number>2</number>
   </numbers>
</foo>
In suds <= 0.3.7, this would be unmarshalled literally as:
foo {
   numbers {
     number = ["1","2"]
   }
}
Or if the <number xsi:type="xs:int"/> had the xsi:type attribute,
foo {
   numbers {
     number = [1,2]
   }
}
because suds was interpreting the schema literally, that is what you got.
In 0.3.8, the Encoded unmarshaller interprets and flattens the encoded array
and gives you what you would expect:
foo {
   numbers = [1,2]
}
A nice python list of integers :) which is symmetrical to what you would pass as an
argument or nested attribute value.  And, this is how rpc/literal and document/literal
services have returned arrays for a long time.
Also, in <= 0.3.7, empty soap encoded arrays were *not* represented as:
foo {
   numbers {
     number = []
   }
}
But rather:
foo {
   numbers {
     number = ''
   }
}
which is broken.
In 0.3.8, this was also fixed.  Empty arrays are represented consistently as [].
BIG WARNING HERE:
Please notice that this feature changes the form of returned soap encoded arrays and WILL 
break some of your code.  For this, I am really sorry and hope that you will agree that 
the benefits outweigh the hassle of porting you code after upgrade.
Regards,
Jeff