Nested Model support in Rails is currently scheduled for Rails 2.3. Yay!
The Rails team has recently organized its community around the Rails Activists group and provided several ways for you to speak your mind about the framework – and one of the best ways to impact the maturation of the framework is to vote for features you’d like to see in upcoming releases.
While I don’t usually like to use this site as a bully pulpit, I have to say that the one feature I’d love to see make it’s way into Rails is nested model mass assignment support. The team teased us with the foundation of an initial implementation but later yanked it since it didn’t quite cover all the cases.
I’ve setup a suggestion on uservoice for exactly this feature. If you’d like to see this support in Rails vote for it now! to be heard.
By the way, I totally acknowledge that I am being less than useful here only in complaining and not actually contributing. Guilty as charged – but to be honest, it’s a hairy problem with a lot of edge cases and sometimes I’m just not that smart.
So be heard with your vote (for this feature or any other!)
tags: ruby, rubyonrails

Hey Ryan,
Hopefully we’ll have it in Rails 2.3. It’s already planned if you see the 2.3 milestone – http://rails.lighthouseapp.com/projects/8994/milestones/24544-23
There are many threads ( actually, way too many ;) ) on the core mailing list about that. But the summary is http://gist.github.com/10793
So, stay tuned :)
Go Team Activist!
You have my sword!
I think it’s great that people are using UserVoice to let the Activist Team – and the Core Team – which initiatives they think are important. And, as Pratik points out, this particular one is cooking along already. And the Activist Team just had a conference call to look at next steps, guided by what the community is telling us is important. So be assured, folks are listening – and results will come as fast as we can make them happen.
At the same time, can I interject just a small note of caution into the “bully pulpit” approach? I hope people will visit the site, spend some time reading, and vote for whatever they think is important – not just visit once and click a button because Ryan is a great guy. That’s the best way for us to hear from everyone.
So, Ryan, thanks for publicizing the UserVoice site. And I hope the rest of you won’t be strangers!
Pratik: That’s heaps! This is a feature that is very core and I’m so happy to see it on the horizon
@Mike – for the record I’m kind of a douchebag :)
And yes, I hope people do more than blindly click on a link because it has my vote. Think for yourselves people.
It’s really great to see this kind of outreach.
Holy crap, it’s now the number one issue on UserVoice. I really feel like a tool now.
Readers, use this as an opportunity to become involved in the framework you love so much and not just as an opportunity for me to pump a single issue.
It is great to see this kind of involvement though, exciting!
+3 votes…
Another thing I would like to see is something related to nested model assignment:
Improve the AR build method so that it not only provides a new record with an id of the associated object but also a reference to the complete object. Why?:
When objects are normally initialized with build they only have an id which is enough to get to associated object. But one situation I had yesterday, when trying to get all logic from controller to the model, was that the object that called build did not yet exist. In this case it would be better to provide a reference to the new object instead. See the example below:
@@code
@object = Object.new @associated_object = @object.build_associated_object # currently doesn’t keep the relation!
@associated_object.object # gives nil!
@@
To solve it in the current situation I used an approach similar to one of Josh Susser http://blog.hasmanythrough.com/2007/1/22/using-faux-accessors-to-initialize-values
Do you see a need as well?
I can’t wait for this feature. +3 votes
And thanks for the blog post to point this feature out, might not have found out otherwise
3+ votes for me.