All,
ITEM #1 -------------------------
background:
Due to name collision problems I need to remove all non __xx__ attributes from the ServiceProxy and Object classes. The Object has been completely cleaned up and the ServiceProxy has been cleaned with the exception of get_instance() and get_enum(). They have been left as is for backwards compatibility. Although I later found out that removing the dict() in Object broke some user code. So, I need to find a home for this and other methods.
For the ServiceProxy, the implementation of get_instance() and get_enum() we moved to a Factory class that is an attribute of the ServiceProxy as __factory__. The idea was the in the future (when get_instance() and get_enum() was deprecated) users would use the factory to create wsdl objects. However, having user access __factory__ was kind of "hacky" so ....
news:
I decided to introduce a 2nd generation API and leave the existing ServiceProxy as is. The concept is that instead of using the ServiceProxy, user would use the Suds Client instead. The client is an object that contains both a proxy for the service, a factory and other relevant objects that make up the client. The client would also contain other convenience methods and attributes such as the Object dict() method. This would work as follows (see README starting @ line 166):
from client import Client
# param is wsdl url and kwargs just like the SeviceProxy client = Client('...')
# factory.create() replaces ServiceProxy.get_instance() and get_enum() person = client.factory.create('Person')
# service method invocation - just like ServiceProxy result = client.service.addPerson(person)
# get a dictionary for the result (Object), replaces Object.dict() mydict = client.dict(result)
Anyway, you get the idea. The client.py exists on trunk and has been tested. Pending comments and/or objections, I'll change the existing ServiceProxy implementation to use the new Client class under the covers to avoid code duplication sometime next week. We can leave the existing ServiceProxy for backwards compatibility for as long as the community wishes to leave it.
Your comments please ....
ITEM #2
I was looking at the Element specification within the XSD specification and noticed that Suds doesn't honor either the *form* attribute or the *nillable* attribute. I've added (and committed) support for both with the exception that pending the following question, I need replace the nil_supported keyword flag check in the marshaller(s) with checking the SchemaProperty.nillable attribute.
Question: Since @nillable is now supported, do we still need the nil_supported keyword/flag? Can everyone using the nil_supported keyword with a value ( False ) please review you WSDLs and determine if this flag is still needed? I'm assuming that if these WSDLs contain ELEMENTS with nillable either (false) or not specified (the default is false), then Suds' new support of <element nillable=""/> provide the same result as having the nil_supported flag (False). If this is true, when we can remove the nil_supported keyword.
An easy way to try this on your WSDL is: Using the latest (r138+) code on trunk change marshaller.py line 119: from
if self.nil_supported:
to:
if content.type.nillable
An run against your services.
Thanks,
Jeff
--- Jeff Ortel RHN Satellite Engineering Centennial (324D) (P) 919-754-4603