What you say below makes sense. The bad code part of it was just my design sense screaming since it's required that there be specific keys, and the values be specific types. Would have been better suited to their own key/value pairs, rather than generic ones.
I'll check more into raising my own soap faults as well. I did find a bug (in web2py, and hopefully it can get a change made to pysimplesoap to support the clean version of the fix I put in) Basically, per soap spec, a soap fault MUST return a 500 HTTP response code. Web2py doesn't. It's an easy modification to make, I threw it into my local copy of web2py (How do I submit a patch, by the way? Just post one on this mailing list? Or maybe I'm missing a really nice bugtracker for web2py that I should know about...). Fixing it required implementing an extension to the dispatcher.dispatcher code, handing in a param (return_status) that defaults to False, but if True the method will return a tuple of (fault, response) with fault being True if the response is a fault, or False if the response is not a fault. That allows web2py to trigger response.status to be 500, rather than the default 200. Where should I submit a patch for pysimplesoap (if this is something you'd be interested in throwing in there)? And how do I make sure that version gets in web2py, as well as a patch gets into web2py to address not returning a 500 response code on soap fault? (Guessing some sort of bug tracking system!) On Jan 4, 8:44 am, Mariano Reingart <reing...@gmail.com> wrote: > On Mon, Jan 3, 2011 at 8:49 PM, Dragonfyre13 <dragonfyr...@gmail.com> wrote: > > Thought this might be interesting to someone, as it took me digging > > through the pysimplesoap code to figure out. So I'll record it here > > for posterity. > > > In web2py, I needed asoapservice that can have one to many sets of a > > a particular element. This caused some issues, as there's not really a > > convention documented for supporting multiple elements posted in, > > without explicitly defining all of them. > > See:http://code.google.com/p/pysimplesoap/wiki/ComplexTypeshttp://code.google.com/p/pysimplesoap/issues/detail?id=4 > > But you are right, that is not documented in deep, I'll make a recipe > with further explanations. > > > > > what I found, was putting a dict in a list, you could get this (taken > > from the "unmarshall" section of the simplexml code, since the > > pysimplesoap does this: > > args = method.children().unmarshall(args_types) > > > # types is a dict of {tag name: convertion function} > > # example: types={'p': {'a': int,'b': int}, 'c': [{'d':str}]} > > # expected xml: <p><a>1</a><b>2</b></p><c><d>hola</d><d>chau</d> > > # returned value: {'p': {'a':1,'b':2}, `'c':[{'d':'hola'}, > > {'d':'chau'}]} > > > Notice in there, that by putting the {'d':str} object in a list, even > > a single element list, it makes it able to be repeated, over and over > > again. No idea how to set a limit on repetitions, or how this would > > react to simply not including a value (is a zero to many, or one to > > many?) but I'm trying it out now. Here's the completed decorator and > > func definition: > > > @service.soap('methodName',returns={'result':bool}, > > args={'data':[{'elemName':str, 'elemValue':str}]}) > > def mymethod(data): > > """ > > Does nothing right now. > > """ > > # the var data is filled with a list of dicts. Each dict has two > > elements, > > # "elemName" and "elemValue", both strings. Can iterate over this, > > and pull > > # out any data required. > > return True > > > So it currently doesn't do anything yet, and the design is bad since I > > was handed a wsdl and told "make that work", but here's outstanding > > questions I have on pysimplesoap/web2pysoapstuff: > > The code seems fine, why you say that it is a bad design? > It does what you need? > > > 1) It doesn't look like there's currently any way to say "int between > > x and y", just that it's an int. Since it's auto generating the wsdl, > > that seems important... > > This cannot be done now, it would require changing the simple type > declaration, using custom types instead of python types (int, float, > etc.). > See reply 4 > > > 2) Same as above goes for data from a particular set. I can validate > > this in the code of the service, but I really have no clue how to get > > that into the wsdl. > > What do you want to do? > See reply 4 > > > 3) How do I get this to throw a specificsoapfault, when there's an > > error? > > I think you can raise any python exception and the library will > convert it to a SoapFault. > If you want to raise an specific SoapFault, you will have to modify the code. > > > 4) Can I make a particular value optional (0-1 repetitions) or a range > > of repetitions? (5-100, 1-4, etc) or is this also something that needs > > to go in the python code, and it just can't make it into the wsdl > > right now? > > This would be relatively easy to implement but it would require a more > complex type definition (using custom list classes and so on) > You can't make it into the wsdl right now, but you can write the wsdl > by hand and do the checks in the code. > > I would recommend you to always do the checks at python level, don't > rely on the wsdl (there are tools that even don't use wsdl at all to > check the call parameters) > > > 5) What are my options with "complex types" or "custom types"? > > Supported, unsupported? (http://oreilly.com/catalog/javasoap/chapter/ > > ch05.html) > > I don't understand your question, both complex and custom types are > supported (up to a limited extent). > > > 6) Still playing around with how to change mysoapresponse up. > > Again, what do you want to do? > If standard response (or request) is not enough, you can use raw xml > for input/output full control (it will merge a simple-xml dom tree if > no type declaration is used). > > With this method, you can handle all cases "unsupported" by this library. > > > Dealing much more with the simplexml.py code than I would have > > thought, as the soapdispatcher.py code is very simple (good thing!) > > Yes, the idea of this library is to get a simple and functionalsoap > implementation. > > Sadly,SOAPis a very complex specification, so if you want to use all > of its features, you end up in a complicated implementation. > The good news are (IMHO) that most of the real world applications need > a simple and standard way to interoperate, using a subset of the > specification, so the exotic features are rarely needed. > > YMMV > > PS: if you want to contribute to the PySimpleSoap project, fell free > to contact me or fill an issue at the project site ;-) BTW, there is a > s...@python.org mailing list dedicated to this topics. > > Best regards > > Mariano Reingarthttp://www.sistemasagiles.com.arhttp://reingart.blogspot.com
