[Fedora-suds-list] suds news
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