11:32 a.m.
All,
I'd like to briefly update everyone on some of the things I'm currently
working on:
In order to support the new features and fix reported bugs, I'm in the
process of refactoring and hopefully evolving the components in Suds
that provide the input/output translations:
* Builder ( translates: XSD objects => python objects )
* Marshaller ( translates: python objects => XML/SOAP )
* Unmarshaller ( translates: soap/xml => python objects )
This evolution will provide better symmetry between these components as
follows:
The Builder and Unmarshaller will produce python (subclass of
sudsobject.Object) objects with:
* __metadata__.__type__ = XSD type (SchemaProperty)
* subclass name ( __class__.__name__ ) = schema-type name.
and
The Marshaller(s), while consuming python objects produced by the
Builder or Unmarshaller, will leverage this standard information to
produce the appropriate output ( XML/SOAP ).
The 0.2.1 code behaves *mostly* like this but ... not quite. Also, the
implementations have some redundancy.
While doing this, it made sense to factor out the common schema-type
"lookup" functionality used by the Builder, Marshallers and Unmarshaller
classes into a hierarchy of "Resolver" classes. This reduces the
complexity and redundancy of the Builder, Marshallers and Unmarshaller
classes and allows for better modularity. Once this refactoring was
complete, the difference between the literal/encoded Marshallers became
very small. Given that the amount of code in the bindings.literal and
bindings.encoded packages was small (and getting smaller) and in the
interest of keeping the Suds code base compact, I moved all of the
marshalling classes to the bindings.marshaller module. All of the
bindings.XX sub-packages will be removed.
The net effect:
All of the Suds major components:
* service proxy
* wsdl
* schema
* resolvers
* output (marshalling)
* builder
* input (unmarshalling)
Now have better:
* modularity
* symmetry with regard to Object metadata.
* code re-use (< 1% code duplication --- i hope)
* looser coupling
... and better provide for the following features/bug-fixes:
* (fix) Proper level of XML element qualification based on <schema
elementFormDefault=""/> attribute. This will ensure that when
elementFormDefault="qualified", Suds will include the proper namespace
on root elements for both literal and encoded bindings. In order for
this to work properly, the literal marshaller (like the encoded
marshaller) needed to be schema-type aware. Had i added the same
schema-type lookup as the encoded marshaller instead of the refactoring
described above, the two classes would have been almost a complete
duplicate of each other :-(
* (enhancement) The builder and unmarshaller used the
schema.Schema.find() to resolve schema-types. They constructed a path
as "person.name.first" to resolve types in proper context. Since the
Schema.find() was stateless, it resolved the intermediate path elements
on every call. The new resolver classes are statefull and resolve child
types *much* more efficiently.
* (enhancement) Add a metadata flag so that marshaller will ouput
innerXML as escaped TEXT content instead of child nodes.
* (future-feature) have the marshaller/unmarshallers do python<=> xs
type conversions such as xs:date, xs:datetime etc .....
Other fixes in my workspace waiting to be commited:
* (fix/enhancement) Name collisions in sudsobject.Object like the
items() method. I've moved all methods (including class methods) to a
Factory class that is included in the Object class as a class attr (
__factory__ ). Now that *all* attributes have python built-in naming,
we should not have any more name collisions. This of course assumes
that no wsdl/schema entity names will have a name with the python
built-in naming convention but I have to draw the line somewhere :-)
I'm pretty jammed at work right now so my time to work on suds is
limited. I have all of these changes and fixes coded and mostly tested.
Once, completely regression tested, I'll release to trunk. If you're
waiting on what seems like a simple fix to hit truck, it's probably been
completed but because it's mixed in these larger changes, it's been
delayed reaching trunk.
Also, I'm going to try and get a public bugzilla site setup to track
features and bugs. As the suds community get larger and larger, my
ability to properly track these things (on top of my current work load)
is getting stretched. I need the community to help me and access to a
public facility such as bugzilla would really help. If you feel that
your bug or feature request has "slipped through the cracks", I
apologize. For now, please remind me on the list.
Thanks to everyone for your interest and help with suds,
Jeff