ActiveResource collections and from_xml

Hello,

ActiveResource currently uses ActiveSupport’s Hash extension’s
definition of from_xml (which in turn just wraps XmlSimple right now)
to parse up XML returned from a serving application.

In Rails, the “serving application” (the application exporting a
resource) will typically call to_xml on the concerned AR object to
generate a chunk of XML which is then picked up by a client
ActiveResource-using application.

The issue is that to_xml will do something like this when called on an
Array (i.e., when rendering XML for a collection, say):

1 ... 2 ... ...

On the ActiveResource side, Hash’s from_xml will right now, due to
XmlSimple, present this as follows (sorry for the pseudo-codish syntax
here):

{
‘entities’ => {
‘entity’ => [ #Instances_of_Hash ]
}
}

Wht’s wrong with this? According to XmlSimple, nothing. However,
given the implementation of to_xml, which I think makes a lot of
sense, it would arguably make more sense for from_xml to return this:

{
‘entities’ => [ #Instances_of_Hash ]
}

Then the collection itself, called ‘entities’, can easily get
logically mapped by ARes to an Array of Entity ARes instances. This
makes more sense for ARes, I think.

Similarly, consider a resource with a nested collection, as follows:

1 ...other attribs... 1 ... 2 ... ...

from_xml will turn this into something like:

{
‘entity’ => {
‘id’ => 1,

‘some-other-entities’ => {
‘some-other-entity’ => [ #Hash ]
}
}
}

What’s undesirable here, in my opinion, is the unnecessary
“some-other-entities”->“some-other-entity” nesting. Here’s a more
preferable representation:

{
‘entity’ => {
‘id’ => 1,

‘some-other-entities’ => [ #Instances_of_Hash ]
}
}

There are also issues with how XmlSimple in its current use in
from_xml deals with single-element arrays.

I corrected the issues with ARes handling of collections as it stands
and wrote some tests. The ticket in question is:
http://dev.rubyonrails.org/ticket/6291 – the latest patch in the
ticket, activeresource_collections_ALTERNATE_with_tests.diff, is what
you should be looking at.

The particularity in my current implementation is that I define a
“fixup” method for ARes, in ARes Connection class, to manipulate the
Hash returned by Hash.from_xml(), into something which I think is much
saner for ARes, given the way to_xml works.

Arguably, and this is where I hope you all chime in, this “fixing up”
actually rightfully belongs in ActiveSupport’s extension of Hash, that
is directly in from_xml. However, there are at least two outstanding
issues in my mind with doing this:

  1. There are other consumers of Hash.from_xml() – both in Rails
    itself, and maybe in outside plugins. I haven’t investigated all of
    them yet, and frankly I’m not sure if they would have to be changed as
    well;

  2. Perhaps more concerning, and partly related to (1), is the fact
    that there are some edge cases which I’m not sure how to handle in the
    general Hash.from_xml case, but which make sense in ARes. Namely, how
    to handle:

1 ...

(i.e., the case where we’ve got a collection with a single entity).
XmlSimple’s ‘forcearray’ is currently set to false in Hash.from_xml,
but for ARes it would make more sense for it to be true, and then if
“entity”.pluralize == parent_node_name (true in the above example),
then “pullup” the entity collection. Not sure if my point is getting
across here, so please ask me to elaborate if necessary.

Question: commit ticket 6291 as it stands for now since it fixes some
collection handling edge case bugs in ARes, refactor 6291, or push
6291’s idea in a more general way into ActiveSupport’s Hash.from_xml?

Thanks,

Bosko M. [email protected]

This didn’t seem to get much attention on -talk… Could someone
please take a look and comment?

-B

---------- Forwarded message ----------
From: Bosko M. [email protected]
Date: Oct 5, 2006 12:12 AM
Subject: ActiveResource collections and from_xml
To: [email protected]

Hello,

ActiveResource currently uses ActiveSupport’s Hash extension’s
definition of from_xml (which in turn just wraps XmlSimple right now)
to parse up XML returned from a serving application.

In Rails, the “serving application” (the application exporting a
resource) will typically call to_xml on the concerned AR object to
generate a chunk of XML which is then picked up by a client
ActiveResource-using application.

The issue is that to_xml will do something like this when called on an
Array (i.e., when rendering XML for a collection, say):

1 ... 2 ... ...

On the ActiveResource side, Hash’s from_xml will right now, due to
XmlSimple, present this as follows (sorry for the pseudo-codish syntax
here):

{
‘entities’ => {
‘entity’ => [ #Instances_of_Hash ]
}
}

Wht’s wrong with this? According to XmlSimple, nothing. However,
given the implementation of to_xml, which I think makes a lot of
sense, it would arguably make more sense for from_xml to return this:

{
‘entities’ => [ #Instances_of_Hash ]
}

Then the collection itself, called ‘entities’, can easily get
logically mapped by ARes to an Array of Entity ARes instances. This
makes more sense for ARes, I think.

Similarly, consider a resource with a nested collection, as follows:

1 ...other attribs... 1 ... 2 ... ...

from_xml will turn this into something like:

{
‘entity’ => {
‘id’ => 1,

‘some-other-entities’ => {
‘some-other-entity’ => [ #Hash ]
}
}
}

What’s undesirable here, in my opinion, is the unnecessary
“some-other-entities”->“some-other-entity” nesting. Here’s a more
preferable representation:

{
‘entity’ => {
‘id’ => 1,

‘some-other-entities’ => [ #Instances_of_Hash ]
}
}

There are also issues with how XmlSimple in its current use in
from_xml deals with single-element arrays.

I corrected the issues with ARes handling of collections as it stands
and wrote some tests. The ticket in question is:
http://dev.rubyonrails.org/ticket/6291 – the latest patch in the
ticket, activeresource_collections_ALTERNATE_with_tests.diff, is what
you should be looking at.

The particularity in my current implementation is that I define a
“fixup” method for ARes, in ARes Connection class, to manipulate the
Hash returned by Hash.from_xml(), into something which I think is much
saner for ARes, given the way to_xml works.

Arguably, and this is where I hope you all chime in, this “fixing up”
actually rightfully belongs in ActiveSupport’s extension of Hash, that
is directly in from_xml. However, there are at least two outstanding
issues in my mind with doing this:

  1. There are other consumers of Hash.from_xml() – both in Rails
    itself, and maybe in outside plugins. I haven’t investigated all of
    them yet, and frankly I’m not sure if they would have to be changed as
    well;

  2. Perhaps more concerning, and partly related to (1), is the fact
    that there are some edge cases which I’m not sure how to handle in the
    general Hash.from_xml case, but which make sense in ARes. Namely, how
    to handle:

1 ...

(i.e., the case where we’ve got a collection with a single entity).
XmlSimple’s ‘forcearray’ is currently set to false in Hash.from_xml,
but for ARes it would make more sense for it to be true, and then if
“entity”.pluralize == parent_node_name (true in the above example),
then “pullup” the entity collection. Not sure if my point is getting
across here, so please ask me to elaborate if necessary.

Question: commit ticket 6291 as it stands for now since it fixes some
collection handling edge case bugs in ARes, refactor 6291, or push
6291’s idea in a more general way into ActiveSupport’s Hash.from_xml?

Thanks,

Bosko M. [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs