On 09/20/2012 09:49 PM, Jason Guiditta wrote:
On 20/09/12 16:16 +0100, Martyn Taylor wrote:
I've created a new topic on the "Ruby on Rails: Talk" forum:
https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-talk
I was directed here by: http://rubyonrails.org/community. If I get
little response on the forum I'll escalate it to the core list.
Regards
Martyn
So, I have been searching around the intertubes today, and from what I
can tell, passing in <something>_attributes was a deliberate design
decision by the rails team[1]. That doesn't make it suck any less, but
it does indicate that at least we aren't the ony ones to hit this
problem. I am still quite suprised that more people are not doing
what we want to do here though. Makes me wonder if perhaps it is more
common to do as lutter and the deltacloud crew have done with cimi,
and not support direct CRUD on nested objects, at least via the api?
We have a requirement to be able to do build/push in a single request.
The API was intended to support this by accepting a Create TargetImage
request with a nested Provider Image.
Not sure, but I found a couple links I wanted to pass along in case
they are of any help:
http://stackoverflow.com/questions/4052677/rails-nested-resources-input-vs-output-format-inconsistency
https://gist.github.com/653925
Thanks. I think this further confirms the issue, and that others are
experiencing the same problem.
I briefly played with the above gist just now, as it seemed similar to
the proposed before_filter idea we discussed earlier, but it had some
syntax problems, and I don't think I'll have time to get through
cleaning it up for proper testing today. If the problem remains
tomorrow, I will try to help look some more.
-j
[1]
http://groups.google.com/group/rubyonrails-core/browse_thread/thread/3c61e00916c365e5/d3d68be5ec9084f5
From that explanation it seems that the developer has chosen the easy
route rather that the correct route. It doesn't seem to be a high level
design decision thinking about the API and how will effect layers
above. But an implementation decision, which follows the easiest route;
in order offer some form of nested resource functionality.
