-
Notifications
You must be signed in to change notification settings - Fork 615
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
namespace_identifier to affect message body and header #362
Comments
i've seen your wsdl and the problem is that the type information are included in a separate file and imported into the wsdl. unfortunately savon doesn't support imports just yet. see #340 but you should be able to manually specify whether you want the elements to be namespaced: |
Ok. Thanks! |
I tried setting element_form_default to :qualified in my client options. It seems to affect the tags in the message but not the header. The header is configured via setting the soap_header option. For now I am just explicitly setting the namespace in the header Hash as described above, but not in the message bodies. Not sure if you want to do anything about that or have an alternate suggestion? |
there's already an open issue for that. i just haven't found the time to work on this, but it needs to be fixed. |
Thanks. I greatly appreciate your time and effort today. |
I'm using savon 2.x master. The API I'm using seems to want a namespace identifier before ALL of the XML tags.
For example. I need a header that looks like this:
And a body that looks like:
When I instantiate the client, I'm using the :namespace_identifier option, which seems to affect only the namespace identifier of the action tag.
However, when I do a client call, I am having to manually set the namespace identifier in the header and body hash. For example:
Note the extensive use of "#{ns}:" prepended to hash keys that yields an XML tag of "<inn:..."
I've been doing it like this for a while with savon 1.2, but its not the cleanest solution. Now that I am in the process of upgrading to 2.x, I thought there might be a better way to do this, perhaps with the namespace_identifier option?
Thanks.
The text was updated successfully, but these errors were encountered: