From bentonc at gmail.com Fri Mar 15 18:36:05 2013 From: bentonc at gmail.com (Charlie Benton) Date: Fri, 15 Mar 2013 12:36:05 -0500 Subject: [Soap-Python] Why does Spyne wrap SOAP inputs in a complexType Message-ID: I have the following web service defined using Spyne. class CapsWebService(ServiceBase): @rpc(String, Integer, _returns=Iterable(String)) def SayHello(ctx, name, times): for i in xrange(times): yield 'Hello, %s' % name The corresponding WSDL generated for the web services inputs is: Why are these inputs being wrapped in a complexType? This forces me to consume the web service in .NET using the following statement: SayHelloResponse response = client.SayHello(new SayHello() { name = "Dave", times = "5" }); As opposed to: SayHelloResponse response = client.SayHello("Dave", "5"); Is there a way to stop Spyne from wrapping the inputs? Am I doing something wrong in either python or .NE that's forcing me to use the longer more cludgey .NET statement to consume the web service? Thanks, Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.risinger at corvisa.com Fri Mar 15 18:57:56 2013 From: anthony.risinger at corvisa.com (C Anthony Risinger) Date: Fri, 15 Mar 2013 12:57:56 -0500 Subject: [Soap-Python] Why does Spyne wrap SOAP inputs in a complexType In-Reply-To: References: Message-ID: <51436124.5050602@corvisa.com> On 03/15/2013 12:36 PM, Charlie Benton wrote: > I have the following web service defined using Spyne. > > class CapsWebService(ServiceBase): > @rpc(String, Integer, _returns=Iterable(String)) > def SayHello(ctx, name, times): > for i in xrange(times): > yield 'Hello, %s' % name > > The corresponding WSDL generated for the web services inputs is: > > > > > > > > > > > Why are these inputs being wrapped in a complexType? This forces me to > consume the web service in .NET using the following statement: > > SayHelloResponse response = client.SayHello(new SayHello() { name = > "Dave", times = "5" }); > > As opposed to: > > SayHelloResponse response = client.SayHello("Dave", "5"); > > Is there a way to stop Spyne from wrapping the inputs? Am I doing > something wrong in either python or .NE that's forcing me to use the > longer more cludgey .NET statement to consume the web service? I could be off-base here, but I think this is expected when using `Document`-style SOAP messages as opposed to `RPC`-style... IMO, RPC is annoying because it makes you take argument order into account. I normally do something like: sig = api.signature('SayHello') sig.SayHelloRequest.name = 'Dave' sig.SayHelloRequest.times = 5 response = sig() ...the above is the exact code i'd write using a small/custom wrapper around the Python SUDS library (technically, i could have passed name/times as keyword args to `signature`, but the above is more explicit). -- C Anthony ----------------------------------------- CONFIDENTIALITY: The information contained in this communication may be confidential and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete any copy of it from your computer system. From burak.arslan at arskom.com.tr Fri Mar 15 19:52:12 2013 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Fri, 15 Mar 2013 11:52:12 -0700 Subject: [Soap-Python] Why does Spyne wrap SOAP inputs in a complexType In-Reply-To: References: Message-ID: <51436DDC.1050707@arskom.com.tr> On 03/15/13 10:36, Charlie Benton wrote: > Why are these inputs being wrapped in a complexType? This forces me to > consume the web service in .NET using the following statement: > > SayHelloResponse response = client.SayHello(new SayHello() { name = > "Dave", times = "5" }); > > As opposed to: > > SayHelloResponse response = client.SayHello("Dave", "5"); > > Is there a way to stop Spyne from wrapping the inputs? Am I doing > something wrong in either python or .NE that's forcing me to use the > longer more cludgey .NET statement to consume the web service? > Hi, Clients that I'm familiar with (which don't include ms-only stuff) run some heuristics to recognize a wrapped function and make it work like the second code snippet above. You can pass _body_style='bare' to @rpc decorator to prevent that wrapping. But you'll most likely get: Exception: body_style='bare' can handle at most one function argument. If you can fix this in a way that doesn't break other tests, I can merge your patch. Best regards, Burak -------------- next part -------------- An HTML attachment was scrubbed... URL: From burak.arslan at arskom.com.tr Wed Mar 27 09:14:11 2013 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Wed, 27 Mar 2013 10:14:11 +0200 Subject: [Soap-Python] The upcoming Spyne-2.10.0 Message-ID: <5152AA53.6010706@arskom.com.tr> Hello, This is to let you know that, as of now, Spyne-2.10.0 is in feature freeze. I'm going to fix failing tests (only two left), add a couple of new ones to see how well the new things that are bolted together hold, update the docs and make a release hopefully in a week or two. The diffstat gives: $ git diff --stat spyne-2.9.4 (...) 96 files changed, 5743 insertions(+), 3239 deletions(-) ... which is quite a lot :) So please test the code at the master branch of http://github.com/arskom/spyne and report any incompatibilities and regressions you might find. This is important, please do test and let me know about the tiniest oddity! It must not be there :) A non-trivial chunk of the changes is due to Stephan Andersson's removing the last bit of serialization logic from ModelBase which moved a lot of code around. (Thanks Stephan!) There are no changes on the SOAP side, except maybe having cleanup_namespaces=True by default as opposed to False in previous versions, which will result in much more compact responses. Also, XmlDocument got better in handling Xml attributes. There are many infrastructure changes though, like proper twisted support and much more mature SQLAlchemy support, which makes Spyne easier to integrate with existing infrastructure. I hope that you find the new version of Spyne useful. As always, feedback is much welcome and appreciated. Best regards, Burak