[Fedora-suds-list] development update

[Jeff Ortel]

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