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).
This method had `form_qualified` in its list of attributes whose values it
attempts to copy over from a referenced schema object, but since that
information should never be copied over from referenced elements (both
referencing and referenced elements must always be qualified) there is no need
to do so. Also, since the current implementation sets the `form_qualified` value
on all newly created SchemaObject instances, this function never actually copied
any `form_qualified` values over from referenced objects.
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.
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.
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
Now implemented in much less code using a simple recursive implementation.
The new implementation has two detail differences:
* dependencies can now be passed as a mutable/unhashable collection
* returned list now contains 'equal' but no longer 'the same' 2-tuple items
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.
The 'history' list was being excessively copied at every recursion level when
it was actually only used as an extra stack. Now the extra elements are simply
pushed/popped to/from the end of the stack instead of copying the whole stack
content every time. This brings the operation down to O(n) instead of O(n*n)
algorithmic complexity.
Updated related release notes.
Many thanks to Bouke Haarsma at BitBucket for detecting & reporting the issue,
as well as doing the research, preparing a suitable test case & preparing the
initial patch.
Jurko Gospodnetić