#1 Distinct types for boolean, date etc.
Although on the client side you can generate SOAP
requests which correctly type values such as dateTime,
date, time, boolean, base64Binary etc, when the code is
used in a server and you receive these values, you
can't properly identify them as such. Can distinct
types be generated for these instead of generating
arbitrary tuple sequences, ints or strings as seems to
be done now.
If there aren't distinct types and you echo back the
parameters you have lost the typing. The same occurs if
you want to forward the request onto some other SOAP
service. If one is doing dumb fowarding, ie., not
worrying about the content, the final recipient isn't
able to get what the original user sent. Having to know
what the final recipient wants and convert stuff into
their correct types isn't practical.
Logged In: YES
user_id=211911
I think the original goal was to make to make the
deserialized types map the way that would make them easiest
to use in Python. I see your point about losing the typing
though on a forwarded message, especially for things like
boolean, dateTime, base64. I think maybe the best way to
proceed is create a Config option that allows you to
specify wrapped types when parsing. What do you think?
Logged In: YES
user_id=128466
I was hoping you would see that it might be beneficial. I
held off suggesting a way of doing it to see if you were
open to making changes first. :-)
I am going to attach a file below which shows in the system
I have for doing a similar thing, how the user may
introduce or override the default mappings to and from the
encoded types.
The first part of the file contains some Python types for
some of the XSD types which can't be expressed natively as
an atomic value. The second part defines routines for
registering encoding/decoding functions and functions to
call them. In encoding an object it will try a few
different ways of determining what it is, ie., class
instance or builtin etc. The last part of the file
registers routines for various of the XSD types.
Note that in this code base64Binary isn't actually being
encoded. This is because the underlying Python/C++ code
which calls this stuff is automagically doing that. Strange
but historically that way.
Also, not shown here as it is handled by underlying code
which calls this. If encode returns None in place of the
XML type string (first item in tuple) it will take second
argument to be a translated version of original object and
it will encode that instead.
Anyway, the idea now is that a user can override the
defaults or add new ones. Take for example an interface to
a database using MySQLdb module. If you have mxDateTime
installed it will return those types when querying
date/time fields. Normally the encoder wouldn't know what
to do with them. By adding a encoder for the mxDateTime
types, and having it return ("xsd:dateTime","2000-etc"),
can have it be automatically converted as required without
the user having to do manual translation.
In using your Python module I installed encoders for
arrayType, structType etc, to return (None,list(object))
and (None,object._asdict). This way they would again be
automatically translated without having to manually
traverse the hierarchy and change it because the encoder
did most of the work.
I don't think I did it yet, but for your stuff I would also
override the decoder for "xsd:boolean" to generate your
booleanType object instead of my own Boolean type. That way
it is automatically set up for the correct types that you
need. Ie., can work both ways to translate to what is
actually required.
Anyway, hope this gives you some interesting ideas on how
it might be solved. If I understand your stuff well enough
(not much), you may want it as part of a specific config or
fall through as global. In my stuff one can register new
encoders/decoders at global scope, or a specific service
object can also override or add just those it needs and it
will not affect anyone else.
Example encode/decode routines.