[Fedora-suds-list] Trunk updated

Thu May 22 13:19:02 UTC 2008

All,

The changes, fixes and enhancements listed below have been committed to 
trunk as of r123.  After further field testing (thanks Noehr at 
Coniuro), a few more patches were applied and trunk seems stable at 
r130. As described in the earlier email, this commit contains a number 
of changes.  Some changes are simple code refactoring.  Others, provide 
either performance enhancements (I found places where I was doing stupid 
things and corrected them), functionality enhancements or bug fixes.

I would greatly appreciate any testing and feedback.

So, what's the impact of Suds users?

[ FIXES ]

* sudsobject.Object no longer contains attributes that can hide wsdl 
defined object attributes.  Although, if a wsdl defines an object with 
python built-in like attributes such as __dict__ or __factory__, then 
all bets are off.  But, I have to make some assumptions and draw the 
line somewhere.

* serviceproxy.ServiceProxy also no longer contains attributes that can 
hide service methods (operations).   This is a little bit of a lie.  I 
haven't removed the get_instance() and get_enum() methods *yet* because 
this will break everyones code.  I've added the __factory__ and changed 
the README but haven't removed the methods but I intend to remove them 
in 0.2.2.

   Question:  Would it be useful to have a function in the suds package 
that would return a service proxy and a
                     factory?  Like this?

     >
     > import suds
     > service, factory = 
suds.get_service('http://google.com/services/wsdl')
     >

     If anyone has a cleaner solution, please let me know.

* The <schema/> attribute elementFormDefault is being processed and if 
equals 'qualified', Suds will (according to my understanding of the 
specs) qualify all elements with a namespace.  This will be useful when 
dealing with services provided by our friends in Redmond ;-)

[ ENHANCEMENTS ]

* The marshaller and unmarshaller classes have been refactored into a 
hierarchy where the base classes are provide basic conversion to/from 
XML.  The subclasses layer on varying levels of type awareness.  So, the 
marshaller.Basic class is schema-type unaware; the marshaller.Literal 
adds more awareness; and the marshaller.Encoded has the most schema-type 
awareness. This is the same for the unmarshallers.  For outbound soap 
messages, only the Literal and Encoded marshallers are used.  For 
inbound soap messages, both unmarshallers are used: Faults are processed 
by the unmarshaleller.Basic and returned values are processed by the 
unmarshaller.Typed object.

WHAT THIS MEANS is that every (outbound) sudsobject.Object attribute and 
every (inbound) XML element is matched to a type defined in the wsdl 
(which includes xsi and soap built-in types).  This lookup is very cheep 
because the Resolver classes used to resolve these types retain context 
so lookups are done by simply looking through a very small list of 
children and matching by name.  Most users should never know the 
difference except for better precision and richer functionality now and 
down the road.

* Better logging.  During the refactoring, better logging statements 
were added.

Is this too much detail?

Regards,

Jeff

-------- Original Message --------
Subject: [Fedora-suds-list] development update
Date: Mon, 19 May 2008 12:32:56 -0400
From: Jeff Ortel <jortel at redhat.com>
Organization: Platform Engineering
To: fedora-suds-list at redhat.com

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

_______________________________________________
fedora-suds-list mailing list
fedora-suds-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-suds-list

-- 
Jeff Ortel
RHN Satellite Engineering
Centennial (324D)
(P) 919-754-4603