Before, passing an empty suds object as an optional parameter value was treated
the same as not passing that parameter's value or passing it None - the value
would not get marshalled into the constructed SOAP request at all.
Now, user can still not have the value marshalled by passing nothing or None,
but passing an empty object will get marshalled as an actual SOAP request XML
element.
This seems correct as passing an empty object and not passing an object are two
distinct use-cases and there are web-services out there (e.g.
`https://ads.google.com/apis/ads/publisher/v201502/LineItemService?wsdl`) that
do differentiate between the two.
Fixes issue filed on BitBucket under:
`https://bitbucket.org/jurko/suds/issues/81/suds-should-support-an-empty-object`
Kudos to Nicholas Chen (nicholaschen at BitBucket) & Mark Saniscalchi
(msaniscalchi at BitBucket) for reporting the issue and preparing the initial
fix.
All code paths that could potentially lead to this class getting used convert
any encountered dictionaries to ``suds.sudsobject.Object`` instances and report
an error in case a corresponding XSD type can not be found.
This function was never actually getting used as it is overridden in all
non-abstract mashaller classes, i.e. in both `Encoded` & `Literal`.
Its description also seemed to contain some content incorrectly copy/pasted from
suds.mx.core.Core.suspend().
Fixes an infinite recursion bug encountered when looking for an XSD type in an
XSD schema that does not contain it but itself defines a type referencing a
recursively defined type from an imported XSD schema. Kudos to Kevin Pors
(krpors on BitBucket) for detecting, analysing & reporting the issue, plus
preparing a working quick-fix.
Updated README.rst.
Added basic unit tests for this function, together with some new cleanup todo
items related to the function's current implementation and test code details.
Now XSD import does not attempt to refetch XSD schemas already constructed
during the same XSD load operation.
Updated todo list.
Updated project release notes.
XSD schema imports are not supposed to be transitive. They only allow the
importing schema to reference entities from the imported schema, but do not
include them as their own content. The current XSD schema merging implementation
seems like it's actually including and propagating all the imported content.
- replaced unnecessary list comprehensions with generator expressions to avoid
creating temporary lists
- used standard boolean check when checking for empty containers
- removed a corpse variable assignment
- PEP-8ified comments & made their style consistent
- used double quotes consistently
- removed unnecessary imports
- replaced star imports with explicit ones
Researched into which namespace should be used to qualify SOAP message tags
corresponding to WSDL message parts when using the document/literal binding
style.
- replaced star imports with explicit ones
- improved module, class & method docstrings
- reordered the XSD schema type list alphabetically
- used double quotes consistently
- minor stylistic code changes
TestTransportUsage.test_operation_request_and_reply() test in the test_client.py
module used a WSDL schema that worked fine for that specific test case but did
not exactly match what the developer originally intended. Part of the WSDL's XSD
schema definition got formatted as an embedded Python bytes literal (b"...")
instead of a simple string, resulting in some extra 'b"' & '"' textual XML data.
The extra text data got ignored by suds when parsing that XSD but it was still
not intended to be there in the first place.
Added an assertion to catch cases where such a problem might try and sneak by us
again in the future.
The code checks that the passed namespace parameter is a list or a tuple, but
the raised exception message mentioned only a tuple as a valid namespace value
structure.
Original data accepted only because of extra suds logic to support invalid XSD
schemas but neither was the data actually a valid XSD schema nor is testing that
logic the purpose of the test in question.