[Fedora-suds-list] Trunk updated

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? 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(a)redhat.com&gt; Organization: Platform Engineering To: fedora-suds-list(a)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(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-suds-list -- Jeff Ortel RHN Satellite Engineering Centennial (324D) (P) 919-754-4603