[Fedora-suds-list] suds news

[Jeff Ortel]

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