suds news
by 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
16 years
Trunk updated
by Jeff Ortel
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(a)redhat.com>
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
16 years
Suds Ticketing System
by Jeff Ortel
All,
I've setup the suds trac project ( https://fedorahosted.org/suds ) to
expose the ticketing system to anonymous users. This should provide a
good way to track suds features and defects. I've gone back over emails
and created tickets on behalf of the author of the email. Please review
the tickets to be sure that I haven't omitted or misrepresented
anything. Since anonymous can create/edit/append tickets, please feel
free to correct/augment existing tickets and add any missing tickets.
There is no need to send me an email when you create/edit a ticket. I
get an email automatically. Also, be sure to fill in the field "Your
email or username:" if you want to get emails as the ticket is processed.
See links at the top of the (trac) project page.
TO VIEW TICKETS:
View Tickets -> Active Tickets
Then, select ticket to view details.
TO CREATE A NEW TICKET:
New Ticket
Then,
* Change the "Your email or username:" field replace "annonyous"
with YOUR email address.
* Fill in the "Summary"
* Fill in "Full Description"
MODIFY A TICKET:
View Tickets -> Active Tickets
Then, select ticket to view details for modify.
**note: Change the "Your email or username:" field replace
"annonyous" with YOUR email address.
Thanks,
Jeff
--
Jeff Ortel
Principal Engineer
Red Hat, Inc.
Raleigh, North Carolina
www.redhat.com
16 years
development update
by Jeff Ortel
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
16 years
An error in wsdl parsing?
by Pablo Caro Revuelta
Hello
Is the first time I am trying connect to a soap web service using using
python. Existing libraries are very poor in my opinion (mainly by the
interface) but I like suds and would like use it because is very pleasant.
But I have a problem with the concrete serviece I need to use and I didn't
find the solution.
The service description is:
https://freeway.demo.lionbridge.com/vojo/FreewayAuth.asmx?WSDL
and I neet call to "Logon" function.
The service runs correctly (I can use it with ZSI)
I tried:
{{{
vojo_auth_uri
= "https://freeway.demo.lionbridge.com/vojo/FreewayAuth.asmx?wsdl"
logger('suds.serviceproxy').setLevel(logging.DEBUG)
auth_proxy = ServiceProxy(vojo_auth_uri)
logon = auth_proxy.get_instance('Logon')
logon.Username.append("user")
logon.Password.append("password")
print auth_proxy.Logon(logon)
}}}
When I run that code I get this error "You must specify both your username and
password.at FreewayAuth.Logon(String Username, String Password)"
The problem is that suds does NOT send a correct xml.
The service expects (as documented in
https://freeway.demo.lionbridge.com/vojo/FreewayAuth.asmx?op=Logon ):
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<Logon xmlns="http://tempuri.org/">
<Username>string</Username>
<Password>string</Password>
</Logon>
</soap:Body>
</soap:Envelope>
But the library send:
<SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:tns="http://tempuri.org/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<tns:Logon>
<Username>
<Username>user</Username>
<Password>password</Password>
</Username>
</tns:Logon>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The error: Note the extra Username tag.
Am I using the library correctly? Is an library error?
Thanks in advance
PD: Please excuse my bad english
--
Pablo Caro Revuelta
pcaro(a)yaco.es
Yaco Sistemas S.L.
http://www.yaco.es
C/ Sierpes 48, 41004 Sevilla (España)
Teléfono: 954 50 00 57
Fax 954 50 09 29
Este mensaje y sus documentos anexos son confidenciales y dirigidos
exclusivamente a los destinatarios de los mismos. Si por error, ha recibido
este mensaje y no es el destinatario, por favor, notifíqueselo al remitente y
no use, informe, distribuya, imprima, copie o difunda este mensaje por ningún
medio.
This message and any attached files are confidential. They are for the
intended recipients only. If an error has misdirected this e-mail to you,
please, notify the author and do not use, disclose, distribute, copy, print
or relay this e-mail.
16 years
Re: [Fedora-suds-list] Proposal to add .innerXML attribute to Object
by Tomasz Maćkowiak
This is how i would like it to work:
whole = factory.get_instance('s:any')
field = ... #contruct suds.sudsobject.Object
field.ID = 5
field.innerXML = 'bar'
whole.field = field
should be output not as
<field id="5" innerXML="bar" />
but as
<field id="5">bar</field>
The contents of innerXML should be escaped.
--
Z poważaniem / Best regards
Tomasz Maćkowiak
16 years
Proposal to add .innerXML attribute to Object
by Jesper Nøhr
Hello list,
As per discussion with kurazu on IRC this morning, and per http://msdn.microsoft.com/hi-in/library/ms440289(en-us).aspx
it seems necessary in some cases to allow for people to construct
arbitrary content of nodes. The problem here being that the
aforementioned API requires you to set XML as content for a value.
Right now, suds will automatically escape the XML.
What I propose is to add a new "magic" attribute to Objects, called
`innerXML` which would make an instance of `safestring` which is a
subclass of unicode. This subclass would have a new attribute, `safe`
and when the marshaller encounters the object to marshal, it will omit
the escaping if this attribute is present (and True.)
You may also create instances of `safestring` anywhere else, and e.g.
use it as the value of a property in something returned by get_instance.
I don't like it much either, but I think this the cleanest way of
getting around it.
Jesper
16 years
trunk patched (r122)
by Jeff Ortel
All,
A patch has been applied to trunk (r122) to remove the strip() when
processing (text) characters in the sax handler.
Regards,
Jeff
16 years
Unmarshaller problem?!
by Paulo Henrique Silva
Hi guys,
I'm getting a strange bug using suds on this service
http://cdsws.u-strasbg.fr/axis/services/Sesame?wsdl.
My code is something like:
proxy = ServiceProxy(Simbad.WSDL)
print proxy.sesame ('M51', 'x')
and the result is something like:
<?xml version="1.0"encoding="UTF-8"?><Sesame
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="http://vizier.u-strasbg.fr/xml/sesame_2.xsd"><!--
Q28920 --><target>UFO</target><Resolver name="Simbad"><INFO>Zero (0)
answers</INFO><INFO>*** This identifier is not present in the
database: NAME UFO</INFO></Resolver><Resolver name="VizieR"><INFO>Zero
(0) answers</INFO><INFO>No table found for:
UFO</INFO></Resolver><Resolver name="Ned"><INFO>Zero (0)
answers</INFO><INFO>!***Connection to Ned
crashed</INFO></Resolver></Sesame>
Here is the problem: Note that there are no spaces between version and
encoding attributes on <?xml and later on Sesame namespace declaration
there are no spaces between two xsi declarations. This make this XML
not well formed and no parser accept to digest this.
When I turn debug on, I see this:
2008-05-15 03:38:16,747 {12055} (serviceproxy.py, 267) [DEBUG] http succeeded:
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><ns1:sesameResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="urn:Sesame"><return xsi:type="xsd:string"><?xml
version="1.0" encoding="UTF-8"?>
<Sesame xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://vizier.u-strasbg.fr/xml/sesame_2.xsd">
<!-- Q28920 -->
<target>UFO</target>
<Resolver name="Simbad">
<INFO>Zero (0) answers</INFO>
<INFO>*** This identifier is not present in the database:
NAME UFO</INFO>
</Resolver>
<Resolver name="VizieR">
<INFO>Zero (0) answers</INFO>
<INFO>No table found for: UFO</INFO>
</Resolver>
<Resolver name="Ned">
<INFO>Zero (0) answers</INFO>
<INFO>!***Connection to Ned crashed </INFO>
</Resolver>
</Sesame>
</return></ns1:sesameResponse></soapenv:Body></soapenv:Envelope>
>From this, seems that somewhere in the unmarshaller, the \n are
replaced and all the lines are stripped, making the errors cited
above.
While I was writing this I found that on sax.py:Handler.characters
there is a strip call! If I remove that strip, everything goes well!
Is that strip really necessary or is this a bug?
Thanks a lot,
-- Paulo Henrique
16 years
