soaplite-devel

Re: [Soaplite-devel] Why does value slot of SOM object not include attribute data?

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

Hey,

I dug a bit deeper...

Maybe what I need to understand here is why the SOAP::SOM object that
is generated by the deserializer has the construct that is the
sub-elements without attributes as the value slot.

The struct has 7 slots:
0) qname
1) attr
2) child
3) chars
4) value
5) lname
6) lattr

The child slot is an accurate representation of the sub-tree with
attributes, but the value slot only has element data (names of
elements as keys, and the text of the elements as values).

So the whole issue is that the value slot does not include attribute
data. So this is not a bug as a design limitation.

I'm back at simply wanting to get at the XML payload of the Body tag.
And I'm wanting to set the xml payload of the body response tag
without a gross hack to keep it from being wrapped in a method tag by
the serializer.

Cheers, jas.

Re: [Soaplite-devel] Why does value slot of SOM object not include attribute data?

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

Hey Martin,

I don't believe the only issue is with the deserializer - I believe it
is also with the _as_data() method of SOAP::SOM. Here is the current
method:

sub _as_data {
    my $self = shift;
    my $pointer = shift;

    SOAP::Data
        -> new(prefix => '', name => o_qname($pointer), name =>
o_lname($pointer), attr => o_lattr($pointer))
        -> set_value(o_value($pointer));
}

First the 'name' key to new() is duplicated - seems like a bug, and
second the value is set to o_value($pointer) - which is just the
simple hash-reference given by the deserializer. This is not recursive
- so unless o_value($pointer) return a valid SOAP::Data instance this
is useless.

I suggest the following recursive fix:

sub _as_data {
  my $self = shift;
  my $node = shift;

  my $data = SOAP::Data->name(o_qname($node))->attr(o_attr($node));

  if (defined o_child($node)) {
    my @children;
    foreach my $child (@{ o_child($node) }) {
      push(@children,$self->_as_data($child));
    }
    $data->set_value(\SOAP::Data->value(@children));
  } else {
    $data->value(o_value($node));
  }

  return $data;
}

This now produces a correct SOAP::Data object with all the attributes
included for the subelements.

Any feedback? jas.

On Sat, Sep 13, 2008 at 11:32 AM, Martin Kutter
<mar...@fe...> wrote:
> ... then we probably should change the deserializer to fill all
> appropriate slots: With a XML node containing XML attributes, clearly
> the attr slot should be filled.
>
> Martin
>
>
> Am Freitag, den 12.09.2008, 17:03 +0530 schrieb Jason Stewart:
>> Hey,
>>
>> I dug a bit deeper...
>>
>> Maybe what I need to understand here is why the SOAP::SOM object that
>> is generated by the deserializer has the construct that is the
>> sub-elements without attributes as the value slot.
>>
>> The struct has 7 slots:
>> 0) qname
>> 1) attr
>> 2) child
>> 3) chars
>> 4) value
>> 5) lname
>> 6) lattr
>>
>> The child slot is an accurate representation of the sub-tree with
>> attributes, but the value slot only has element data (names of
>> elements as keys, and the text of the elements as values).
>>
>> So the whole issue is that the value slot does not include attribute
>> data. So this is not a bug as a design limitation.
>>
>> I'm back at simply wanting to get at the XML payload of the Body tag.
>> And I'm wanting to set the xml payload of the body response tag
>> without a gross hack to keep it from being wrapped in a method tag by
>> the serializer.
>>
>> Cheers, jas.
>>
>
>

Re: [Soaplite-devel] Why does value slot of SOM object not include attribute data?

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

Hey everyone,

Is there any feedback on this?

I would like the output of dataof() to return a SOAP::Data object that
can be serialized into the XML that it was created from - and
currently it is broken. My proposed patch would fix this.

Cheers, jas.

On Sun, Sep 14, 2008 at 12:32 PM, Jason Stewart
<jas...@gm...> wrote:
> Hey Martin,
>
> I don't believe the only issue is with the deserializer - I believe it
> is also with the _as_data() method of SOAP::SOM. Here is the current
> method:
>
> sub _as_data {
>    my $self = shift;
>    my $pointer = shift;
>
>    SOAP::Data
>        -> new(prefix => '', name => o_qname($pointer), name =>
> o_lname($pointer), attr => o_lattr($pointer))
>        -> set_value(o_value($pointer));
> }
>
> First the 'name' key to new() is duplicated - seems like a bug, and
> second the value is set to o_value($pointer) - which is just the
> simple hash-reference given by the deserializer. This is not recursive
> - so unless o_value($pointer) return a valid SOAP::Data instance this
> is useless.
>
> I suggest the following recursive fix:
>
> sub _as_data {
>  my $self = shift;
>  my $node = shift;
>
>  my $data = SOAP::Data->name(o_qname($node))->attr(o_attr($node));
>
>  if (defined o_child($node)) {
>    my @children;
>    foreach my $child (@{ o_child($node) }) {
>      push(@children,$self->_as_data($child));
>    }
>    $data->set_value(\SOAP::Data->value(@children));
>  } else {
>    $data->value(o_value($node));
>  }
>
>  return $data;
> }
>
> This now produces a correct SOAP::Data object with all the attributes
> included for the subelements.
>
> Any feedback? jas.
>
> On Sat, Sep 13, 2008 at 11:32 AM, Martin Kutter
> <mar...@fe...> wrote:
>> ... then we probably should change the deserializer to fill all
>> appropriate slots: With a XML node containing XML attributes, clearly
>> the attr slot should be filled.
>>
>> Martin
>>
>>
>> Am Freitag, den 12.09.2008, 17:03 +0530 schrieb Jason Stewart:
>>> Hey,
>>>
>>> I dug a bit deeper...
>>>
>>> Maybe what I need to understand here is why the SOAP::SOM object that
>>> is generated by the deserializer has the construct that is the
>>> sub-elements without attributes as the value slot.
>>>
>>> The struct has 7 slots:
>>> 0) qname
>>> 1) attr
>>> 2) child
>>> 3) chars
>>> 4) value
>>> 5) lname
>>> 6) lattr
>>>
>>> The child slot is an accurate representation of the sub-tree with
>>> attributes, but the value slot only has element data (names of
>>> elements as keys, and the text of the elements as values).
>>>
>>> So the whole issue is that the value slot does not include attribute
>>> data. So this is not a bug as a design limitation.
>>>
>>> I'm back at simply wanting to get at the XML payload of the Body tag.
>>> And I'm wanting to set the xml payload of the body response tag
>>> without a gross hack to keep it from being wrapped in a method tag by
>>> the serializer.
>>>
>>> Cheers, jas.
>>>
>>
>>
>

Re: [Soaplite-devel] Why does value slot of SOM object not include attribute data?

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

Hey Martin,

On Sat, Sep 13, 2008 at 11:32 AM, Martin Kutter
<mar...@fe...> wrote:
> ... then we probably should change the deserializer to fill all
> appropriate slots: With a XML node containing XML attributes, clearly
> the attr slot should be filled.

Here is what I find about the deserializer:
deserialize() first calls decode() and then calls decode_object()
which calls decode_value()

decode_value() calls decode_object() for each child element.

decode_value() returns the $child_name and the $child_value.

decode_value() does *not* encode the attributes into the $child_value
in any way. So that is the main issue.

Here is a meta point. I have no idea why decode_object() is ever
called by deserialize - presumably it sets up some important SOAP
internal information. But all the XML data is present after the call
to decode(). The building up of the o_value slot for the SOM object is
a waste of time as far as I can tell - given that the return value of
decode() is a perl data structure representation of the XML, why build
up a second one that is missing data?

I don't think the SOM methods should use the o_value slot, and instead
should use the complete data structure that is present in the _content
key of the SOM object.

Given how new I am at the SOAP code, it is very likely I've
misunderstood something.

Any feedback?

Cheers, jas.

Re: [Soaplite-devel] Why does value slot of SOM object not include attribute data?

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

Hey All,

Is there any feedback on this?

I would like to clean up the deserialize(), decode(), decode_object(),
decode_value() maze - but I don't understand the implications of how
these subs are inter-connected.

My reading of the code is that the information that is stored in the
o_value slot of the SOM object is *useless* - the attribute
information has been discarded. Since the deserializer has already
parsed this and stored it all in the _content element of the SOM
object - why is this being re-parsed?

Cheers, jas.

On Sun, Sep 14, 2008 at 1:17 PM, Jason Stewart
<jas...@gm...> wrote:
> Hey Martin,
>
> On Sat, Sep 13, 2008 at 11:32 AM, Martin Kutter
> <mar...@fe...> wrote:
>> ... then we probably should change the deserializer to fill all
>> appropriate slots: With a XML node containing XML attributes, clearly
>> the attr slot should be filled.
>
> Here is what I find about the deserializer:
> deserialize() first calls decode() and then calls decode_object()
> which calls decode_value()
>
> decode_value() calls decode_object() for each child element.
>
> decode_value() returns the $child_name and the $child_value.
>
> decode_value() does *not* encode the attributes into the $child_value
> in any way. So that is the main issue.
>
> Here is a meta point. I have no idea why decode_object() is ever
> called by deserialize - presumably it sets up some important SOAP
> internal information. But all the XML data is present after the call
> to decode(). The building up of the o_value slot for the SOM object is
> a waste of time as far as I can tell - given that the return value of
> decode() is a perl data structure representation of the XML, why build
> up a second one that is missing data?
>
> I don't think the SOM methods should use the o_value slot, and instead
> should use the complete data structure that is present in the _content
> key of the SOM object.
>
> Given how new I am at the SOAP code, it is very likely I've
> misunderstood something.
>
> Any feedback?
>
> Cheers, jas.
>

Re: [Soaplite-devel] Why does value slot of SOM object not include attribute data?

[Martin K. <mar...@fe...>]

Hi Jason,

your proposed patch reads fine - I'll try it out.

I don't know whether o_value is used somewhere, or whether there has
just been some planned usage which has been left unimplemented  - I'll
have to look it up.

SOAP::Lite's biggest problem by now is that the test suite is relatively
weak, so we cannot tell whether some change breaks existing SOAP::Lite
applications. And SOAP::Lite is so widespread that breaking existing
code is a pretty bad thing...

Martin

Am Donnerstag, den 18.09.2008, 13:56 +0530 schrieb Jason Stewart:
> Hey All,
> 
> Is there any feedback on this?
> 
> I would like to clean up the deserialize(), decode(), decode_object(),
> decode_value() maze - but I don't understand the implications of how
> these subs are inter-connected.
> 
> My reading of the code is that the information that is stored in the
> o_value slot of the SOM object is *useless* - the attribute
> information has been discarded. Since the deserializer has already
> parsed this and stored it all in the _content element of the SOM
> object - why is this being re-parsed?
> 
> Cheers, jas.
> 
> On Sun, Sep 14, 2008 at 1:17 PM, Jason Stewart
> <jas...@gm...> wrote:
> > Hey Martin,
> >
> > On Sat, Sep 13, 2008 at 11:32 AM, Martin Kutter
> > <mar...@fe...> wrote:
> >> ... then we probably should change the deserializer to fill all
> >> appropriate slots: With a XML node containing XML attributes, clearly
> >> the attr slot should be filled.
> >
> > Here is what I find about the deserializer:
> > deserialize() first calls decode() and then calls decode_object()
> > which calls decode_value()
> >
> > decode_value() calls decode_object() for each child element.
> >
> > decode_value() returns the $child_name and the $child_value.
> >
> > decode_value() does *not* encode the attributes into the $child_value
> > in any way. So that is the main issue.
> >
> > Here is a meta point. I have no idea why decode_object() is ever
> > called by deserialize - presumably it sets up some important SOAP
> > internal information. But all the XML data is present after the call
> > to decode(). The building up of the o_value slot for the SOM object is
> > a waste of time as far as I can tell - given that the return value of
> > decode() is a perl data structure representation of the XML, why build
> > up a second one that is missing data?
> >
> > I don't think the SOM methods should use the o_value slot, and instead
> > should use the complete data structure that is present in the _content
> > key of the SOM object.
> >
> > Given how new I am at the SOAP code, it is very likely I've
> > misunderstood something.
> >
> > Any feedback?
> >
> > Cheers, jas.
> >
> 

Re: [Soaplite-devel] Why does value slot of SOM object not include attribute data?

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

Hey Martin,

On Thu, Sep 18, 2008 at 11:30 PM, Martin Kutter
<mar...@fe...> wrote:
> Hi Jason,
>
> your proposed patch reads fine - I'll try it out.

cool, thanks!

> I don't know whether o_value is used somewhere, or whether there has
> just been some planned usage which has been left unimplemented  - I'll
> have to look it up.
>
> SOAP::Lite's biggest problem by now is that the test suite is relatively
> weak, so we cannot tell whether some change breaks existing SOAP::Lite
> applications. And SOAP::Lite is so widespread that breaking existing
> code is a pretty bad thing...

Ah, good to know that. How can I help? I have a contract that will pay
me money to help SOAP::Lite improve itself.

Can I add more test cases? If so which ones would be good to focus on?

Does the documentation need updating? Which parts? Do new pieces need
adding - I heard someone mention the idea of a cookbook.

Does the code need to be re-worked? I don't have much of an issue with
the code as it stands - but I do find a large number of subroutines
that have similar names and similar purposes and aren't exactly clear
as to what they do. But that is because I am new to the codebase.

Any other ways that I could spend someone else's money and help the
Perl and SOAP::Lite community?

Cheers, jas.