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