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):
<entities>
  <entity>
    <id>1</id>
    ...
  </entity>
  <entity>
    <id>2</id>
    ...
  </entity>
  ...
</entities>
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:
<entity>
  <id>1</id>
   ...other attribs...
  <some-other-entities>
    <some-other-entity>
      <id>1</id>
      ...
    </some-other-entity>
    <some-other-entity>
      <id>2</id>
      ...
    </some-other-entity>
     ...
  </some-other-entities>
</entity>
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:
<entities>
  <entity>
    <id>1</id>
    ...
  </entity>
</entities>
(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 Milekic <bosko.milekic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
http://www.crowdedweb.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---
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):
<entities>
 <entity>
   <id>1</id>
   ...
 </entity>
 <entity>
   <id>2</id>
   ...
 </entity>
 ...
</entities>
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:
<entity>
 <id>1</id>
  ...other attribs...
 <some-other-entities>
   <some-other-entity>
     <id>1</id>
     ...
   </some-other-entity>
   <some-other-entity>
     <id>2</id>
     ...
   </some-other-entity>
    ...
 </some-other-entities>
</entity>
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:
<entities>
 <entity>
   <id>1</id>
   ...
 </entity>
</entities>
(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 Milekic <bosko.milekic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
http://www.crowdedweb.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---
This didn''t seem to get much attention on -talk... Could someone
please take a look and comment?
-B
---------- Forwarded message ----------
From: Bosko Milekic <bosko.milekic@gmail.com>
Date: Oct 5, 2006 12:12 AM
Subject: ActiveResource collections and from_xml
To: rubyonrails-talk@googlegroups.com
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):
<entities>
  <entity>
    <id>1</id>
    ...
  </entity>
  <entity>
    <id>2</id>
    ...
  </entity>
  ...
</entities>
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:
<entity>
  <id>1</id>
   ...other attribs...
  <some-other-entities>
    <some-other-entity>
      <id>1</id>
      ...
    </some-other-entity>
    <some-other-entity>
      <id>2</id>
      ...
    </some-other-entity>
     ...
  </some-other-entities>
</entity>
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:
<entities>
  <entity>
    <id>1</id>
    ...
  </entity>
</entities>
(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 Milekic <bosko.milekic@gmail.com>
http://www.crowdedweb.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---