soaplite-devel

[Soaplite-devel] Fwd: More info on SOAP::Lite document/literal

[Jason S. <jas...@gm...>]

Hey Soapers,

Here is a message I just posted to the MOBY group.

questions:
1) Why does SOAP::SOM::match() discard all the attributes on internal
XML elements? Isn't this a bug?
2) Why doesn't the SOM class have a method like document() that
returns the XML payload of the soap:Body tag? This seems important for
easy implementation of document/literal encoding.

Cheers, jas.


---------- Forwarded message ----------
From: Jason Stewart <jas...@gm...>
Date: Wed, Sep 10, 2008 at 7:58 PM
Subject: More info on SOAP::Lite document/literal
To: Core developer announcements <mob...@li...>


Hey Eddie,

So I dug a bit on the server side and this is what I found.

If your server class subclasses from SOAP::Server::Parameters, the
method will get an extra parameter of type SOAP::SOM which gives
access to all the request information. That object contains a lot of
methods for searching the soap envelope - but it converts all the data
it finds into a SOAP::Data instance - which throws away all attributes
not located at the root of the data being returned. For example if the
XML looked like this:

<soap:Body>
 <q0:sayHello xmlns="urn:HelloWorld#">
   <name>Joe Blow</name>
   <givenName middlename="Windy">Joe</givenName>
 </q0:sayHello>
</soap:Body>

and we did a query like $root = $som->dataof('//Body'), then $root
would be the soap:Body and we would see all of the sub-elements but
not their attributes. Only if we do $gn = $som->dataof('//givenName')
do we actually get the givenName element with the middlename attribute
still intact.

But the $som object has all the information in an internal hash table
- both as a hash table representation of the entire message and the
HTTP::Request object with the original XML.

What I don't understand is why when the dataof() method traverses the
internal hash table structure it throws away all the attributes not on
the root element being returned.

Also, I don't understand why there isn't a method that just returns
the content of the soap:Body element as plain XML - this should be the
default behavior for document/literal. I would like to see a call
something like $xml = $som->document();

Any thoughts of how I could make this interface most useful for MOBY
purposes? I will have to alter the internal SOAP::Lite code, and send
the patches to the maintainers.

Cheers, jas.

Re: [Soaplite-devel] Fwd: More info on SOAP::Lite document/literal

[Jason S. <jas...@gm...>]

Hey Martin,

On Fri, Sep 12, 2008 at 1:49 AM, Martin Kutter <mar...@fe...> wrote:

> 2) What should ->document() do? return the plain XML? Returning the
> content of the soap:Body element is less useful as it may seem - there
> may be information in the header, too.

I was thinking that document() should return the XML content of the
Body tag, but after digging a bit more I think it is unnecessary - as
the SOM class has all the needed methods: body, envelope, header, etc,
but there is the bug with attributes that is making them not useful.

It seems a bit redundant to serialize them, and then deserialize them,
but not such a big deal.

Again, fixing the attribute bugs would really solve this.

> One current workaround could be setting ->outputxml(1) on the SOAP
> object and processing the XML by other means (like XML::Simple or the
> like).

But doesn't this only affect the *client*? This is needed for the *server*.

Cheers, jas.

Re: [Soaplite-devel] Fwd: More info on SOAP::Lite document/literal

[Robbie B. <rob...@gm...>]

2008/9/12 Jason Stewart <jas...@gm...>:
>
> Again, fixing the attribute bugs would really solve this.
>

I'm sure if you gave Martin a patch it would be most welcome ;)