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.
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.
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.
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.
Suds now correctly handles twisted use-cases as seen in some M$ web services,
and whose one possible structure has been illustrated by the
test_recursive_WSDL_import() test in the test_client.py test module.
Note that this has nothing to do with recursive XSD schema imports which still
have known issues.
Updated todo list.
- less duplication
- test specific test data now contained in those tests
- test data can now be constructed with custom XSD target namespace
- tests depending on imported & importing WSDL target namespaces now specify
them explicitly
Reduced test data duplication and made the data more parametrizable so we may
use the same data for testing more WSDL import variations.
Moved some more parts of the WSDL import test data into the imported WSDL
schema.
When one WSDL imports another, this does not mean that the components from the
imported WSDL become part of the importing WSDL, but only means that importing
WSDL's components may now reference components from the imported WSDL.
The fact that suds currently imports actual components into the importing WSDL
is in fact a possible bug (unless it is just a part of some internal
implementation detail with no publicly visible side-effects, but even then such
a kludge should be made clearer in code).
Our original research was based on superficial Internet resources and lead us
down the wrong path. Reference & top-level XSD elements are always considered
qualified and that fact is not affected by any `form` or `elementFormDefault`
attribute values.
A reference XSD element's 'form' value is now correctly read from its referenced
element.
This fix:
* fixes all tests in test_xsd_element.py previously marked as xfail,
* corrects buggy test data in test_request_construction.py and
* resolves project issue #49 on BitBucket.
Updated release notes.
Updated todo list.
New tests marked as expected to fail demonstrate a bug in the original suds
implementation's XSD element `form` attribute value handling. It seems that suds
uses incorrectly detects a referencing element's `form` attribute value - it
should but does not pick up the attribute value from the referenced element
instead of the referencing one (whether it is set directly or using their
schema's `elementFormDefault` attribute).
Updated todo list.
Renamed the suds.xsd.deplist module to suds.xsd.depsort.
Removed the DepList class and replaced its main/only functionality with a single
dependency_sort() function taking a dependency dictionary and returning the same
list that used to be returned by the DepList.sort() method.
The returned list's contents matches the items returned by the dependency
dictionary's items() method, but sorted so that dependencies come first.
Updated project release notes.
Additional included changes:
* cleaned up the test_dependency_sort.py test module - cleanly separated
basic tests, test utilities and test utility tests
* added a test to make sure dependency_sort() does not modify its input data
* documented that any entries found listed as dependencies, but that do not
have their own dependencies listed as well, are logged & ignored
There private members were never intended to be a part of the class's published
interface, their docs were incorrect before the last stylistic cleanup done on
this module and the related private implementation details are planned to be
changed in the near future as well.
Originally the tests were prepared based on the current DocumentCache.put()
which appears to accept only suds.sax.element.Element instances as input.
However, after reviewing the original suds project and the current suds
implementation, it seems that this is actually a suds bug and that it should
accept suds.sax.document.Document instances instead.
Without this, suds.reader.DocumentReader passes suds.sax.document.Document
instances to the cache which then get silently ignored.
The bug was introduced in one of the final commits in the original suds project
(around the end of 2011) where suds.sax.document.Document class was refactored
to no longer inherit from suds.sax.element.Element.
To maintain backward compatibility, for now we still expect to support passing
suds.sax.element.Element instances to suds.cache.DocumentCache.put() even though
it seems the rest of the suds implementation never does this.
For now just tests:
- basic Element construction,
- construction name parameter handling
- childAtPath() method
Updated todo list, including adding many new todo items related to adding new
tests.
We want the test subprocesses to use the same sys.path as its calling process.
However, our test subprocesses get run in a different folder so we need to
manually convert any empty-string sys.path entries to the current folder path
before passing that sys.path off to a new test subprocess.
The test suite is no longer installed together with the project and can now be
run from the project's source distribution. This resolves the issue of the suds
test suite confusing users by getting installed as a top level tests package in
their Python environment.
Project to be tested now need to be explicitly installed prior to running its
tests using pytest, except in case of Python 2 tests being run from the top
level project folder. This requires the user to install the project (suggested
way is to install it in editable mode using 'pip install -e') but also allows
him to run the tests on other non-sandbox project versions, e.g. an externally
installed version.
Project testing now requires the six Python 2/3 compatibility support package
(installed automatically, together with other test requirements).
Test support code now moved to a separate testutils package located under the
tests folder.
Updated project README.rst & HACKING.rst docs.
Minor stylistic changes.
py2to3 does not support reading source files with an explicitly specified UTF-8
BOM prior to Python 3.2. This was causing errors when using it to process two
of our project files.
Updated relevant HACKING.rst documentation.
Jurko Gospodnetić