# Does Rails need more useful form helpers?

**URL:** <https://www.ruby-forum.com/t/does-rails-need-more-useful-form-helpers/58661>\
**Category:** Rails\
**Created:** [April 24, 2006, 5:02pm UTC](https://www.ruby-forum.com/t/does-rails-need-more-useful-form-helpers/58661 "2006-04-24T17:02:56Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![furrot](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/3da27b/32.png) [@furrot](https://www.ruby-forum.com/u/furrot)\
**Post date:** [April 24, 2006, 5:02pm UTC](https://www.ruby-forum.com/t/does-rails-need-more-useful-form-helpers/58661/1 "2006-04-24T17:02:56Z")

</div>

I have been using rails professionally for only a month and a half now,  
but I am continually running into problems with form helpers and  
accessing multiple objects on a single page. To whit:

1. While text\_field and text\_area and such all support the :index  
option, the select helper does not.

2. When appending the text ‘[]’ to a helper’s object name, the id is  
inserted into the brackets — but only for existing objects. While it  
is understandably difficult as new objects have no ids, a method must  
exist somewhere to provide these form helpers with a unique way to  
communicate their unique data to their responding controllers. One  
suggestion is to create the option to specify the object attribute that  
will be used to fill the '[]'s. The example for which I’m having to work  
around this is an administrative form to generate promotional contact  
forms. These forms each have up to 6 questions and each question can  
have up to 4 answers. Thus in the model, Promo has\_many PromoQuestion  
which has\_many PromoAnswer. So I am dealing with having to iterate over  
three levels of hierarchical data both in the edit form and in the  
creation form. It does not seem Rails is designed to handle this type of  
form terribly simply. While I understand that this type of form is  
possible, its implementation seems far from elegant.

3. Rails hierarchical model objects seem to support the creation of a  
tree of new objects that can then be saved with @parent.save. But  
modifying this same tree afterwards does not. Should there not be a way  
to modify attributes of existing child objects and mark them as “to be  
saved” so that when @parent.save is called to update the parent, all the  
child objects are also updated? This does not seem to be the case, as I  
experienced with the self-same promo example above. Calling @parent.save  
after modifying @parent.child.attributes = {…} does not save the  
modifications to the child.

Perhaps there are undocumented features of which I am not aware. If this  
is the case, then my issue becomes one with the documentation.

And perhaps I just do not understand the elegant way to perform such  
tasks as those above. If so, I am eager to learn, and would greatly  
appreciate being pointed to the appropriate documentation.

---

<div class="post-metadata">

**Author:** ![furrot](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/3da27b/32.png) [@furrot](https://www.ruby-forum.com/u/furrot)\
**Post date:** [April 24, 2006, 5:44pm UTC](https://www.ruby-forum.com/t/does-rails-need-more-useful-form-helpers/58661/2 "2006-04-24T17:44:51Z")

</div>

I forgot to complete my sugestion in #2 above. If one could set the  
attribute used with the []s in form helpers, I could, in my example  
above, use question\_number and answer\_number to distinguish data for the  
various child objects regardless of whether they were new objects to be  
created or existng objects to be updated.

This brings up another issue that I feel should have a simple solution.  
The solution above only works if the question\_number AND answer\_number  
are used to identify the answer objects. Currently the [] notation for  
form helpers does not allow the definition of multiple indices.

But this above solution may not even be an acceptable final solution.  
New objects may not have something as simple as a question\_number with  
which to reference themselves. And yet it seems something is needed to  
allow the creation of multiple dependent items in a single form. Perhaps  
some means of creating temporary ids for each new object, saving them to  
the flash and using those ids to distinguish []-marked attributes for  
new objects.

Another suggestion would be a way to tell a form helper about a  
hierarchy of objects (or have it intuitively deduce them?). Ideally, it  
would seem that while the Promo object’s attributes exist in params as  
promo[title], promo[description] and so forth that its children’s data  
should exist in params as promo[promo\_questions][id][question\_text] and  
promo[promo\_questions][id][promo\_answers][id][answer\_text] (where “id”  
would be replaced by the actual id of the existing object or an empty  
string for new objects). This should then be able to be passed to  
@promo.update\_attributes() and @promo.new() alike to create or update  
all these items in one clean, elegant swoop.

And finally, as I said in my previous post, perhaps this elegance exists  
and I simply do not know about it. Or perhaps this elegance does not  
exist for some intended purpose or reason.

---

<div class="post-metadata">

**Author:** ![furrot](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/3da27b/32.png) [@furrot](https://www.ruby-forum.com/u/furrot)\
**Post date:** [April 25, 2006, 1:38am UTC](https://www.ruby-forum.com/t/does-rails-need-more-useful-form-helpers/58661/3 "2006-04-25T01:38:03Z")

</div>

Stephen F. wrote:

> 1. While text\_field and text\_area and such all support the :index  
> option, the select helper does not.

The select and collection\_select helpers support the index option  
in their html\_options hash, so you have to do something like:

```
select :object, :method, {}, :index => 3

```

> 1. When appending the text ‘[]’ to a helper’s object name, the id is  
> inserted into the brackets — but only for existing objects. While it  
> is understandably difficult as new objects have no ids, a method must  
> exist somewhere to provide these form helpers with a unique way to  
> communicate their unique data to their responding controllers. One

I will discuss this in a reply to your follow-up email.

> 1. Rails hierarchical model objects seem to support the creation of a  
> tree of new objects that can then be saved with @parent.save. But  
> modifying this same tree afterwards does not. Should there not be a way  
> to modify attributes of existing child objects and mark them as “to be  
> saved” so that when @parent.save is called to update the parent, all the  
> child objects are also updated? This does not seem to be the case, as I  
> experienced with the self-same promo example above. Calling @parent.save  
> after modifying @parent.child.attributes = {…} does not save the  
> modifications to the child.

I agree that a common method for both creating and updating a tree of AR  
objects would greatly simplify controller code. I have a plugin  
half-written  
that does just that, keeping track of what attributes and associations  
have been changed, so that a save of the parent object does all the  
work.

–  
We develop, watch us RoR, in numbers too big to ignore.

---

<div class="post-metadata">

**Author:** ![furrot](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/3da27b/32.png) [@furrot](https://www.ruby-forum.com/u/furrot)\
**Post date:** [April 25, 2006, 6:09pm UTC](https://www.ruby-forum.com/t/does-rails-need-more-useful-form-helpers/58661/4 "2006-04-25T18:09:41Z")

</div>

My apologies about the :index option for select’s. I thought I tried  
that but I guess I didn’t.

> In order to use multiple indices you have to either use the \_tag  
> versions of the form helpers, or set the name explicitly:
> 
> \<% @promo.questions.each\_with\_index |@q, qnum| do  
> prefix = “promo[promo\_questions][#{qnum}]” %\>  
> \<%= text\_field :q, :question\_text, :name =\> prefix + ‘[question\_text]’  
> %\>  
> \<% @q.answers.each\_with\_index |@a, anum| do %\>  
> \<%= text\_field :a, :answer\_text, :name =\> prefix +  
> “[answer\_text][#{anum}]” %\>  
> \<% end  
> end %\>

You agree, I assume, that this is an ugly approach not worthy of the  
elegance of rails. In my opinion, it would make for much cleaner rails  
applications if rails understood multiple indices (e.g.: :index =\>  
[question\_number, answer\_number]) or naturally handled hierarchical  
data. Or both.

> A common synthetic reference id like a question number is probably  
> better than using the id attribute for existing objects combined with a  
> unique temporary id for new object. Existing object ids can either  
> be determined from their synthetic ids, or placed in the form as  
> hidden fields.

It was an off-the-cuff thought. I agree, two sets of ids is not a good  
idea. I was worried that if synthetic reference ids became the primary  
method of handling these situations, applications would eventually crop  
up where such an id could not be synthesized. However, I’m not sure what  
that situation would be. Collections of new objects being generated all  
at once need to be referenced somehow, I presume.

> An update\_attributes method that worked hierarchically like this would  
> be nice.

I agree. I think this is the best solution so far. Personally, I’d like  
to see it work with both update\_attributes() and new(). Perhaps rails  
can use array index 0 to signify new items to be added, since this will  
never be a database record id. All new object data can be placed into an  
array underneath this index while existing objects to be modified would  
remain under array indices matching their ids. I think this solution  
both covers a generic scope of applications and has the elegance I’ve  
come to expect from rails. Are there any problems with this solution I  
haven’t thought of?

---

<div class="post-metadata">

**Author:** ![furrot](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/3da27b/32.png) [@furrot](https://www.ruby-forum.com/u/furrot)\
**Post date:** [April 25, 2006, 2:11am UTC](https://www.ruby-forum.com/t/does-rails-need-more-useful-form-helpers/58661/5 "2006-04-25T02:11:25Z")

</div>

Stephen F. wrote:

> I forgot to complete my sugestion in #2 above. If one could set the  
> attribute used with the []s in form helpers, I could, in my example  
> above, use question\_number and answer\_number to distinguish data for the  
> various child objects regardless of whether they were new objects to be  
> created or existng objects to be updated.

Yes, you can use the :index option to uniquely number or name both new  
and existing objects.

> This brings up another issue that I feel should have a simple solution.  
> The solution above only works if the question\_number AND answer\_number  
> are used to identify the answer objects. Currently the [] notation for  
> form helpers does not allow the definition of multiple indices.

In order to use multiple indices you have to either use the \_tag  
versions of the form helpers, or set the name explicitly:

\<% @promo.questions.each\_with\_index |@q, qnum| do  
prefix = “promo[promo\_questions][#{qnum}]” %\>  
\<%= text\_field :q, :question\_text, :name =\> prefix + ‘[question\_text]’  
%\>  
\<% @q.answers.each\_with\_index |@a, anum| do %\>  
\<%= text\_field :a, :answer\_text, :name =\> prefix +  
“[answer\_text][#{anum}]” %\>  
\<% end  
end %\>

> But this above solution may not even be an acceptable final solution.  
> New objects may not have something as simple as a question\_number with  
> which to reference themselves. And yet it seems something is needed to  
> allow the creation of multiple dependent items in a single form. Perhaps  
> some means of creating temporary ids for each new object, saving them to  
> the flash and using those ids to distinguish []-marked attributes for  
> new objects.

A common synthetic reference id like a question number is probably  
better than using the id attribute for existing objects combined with a  
unique temporary id for new object. Existing object ids can either  
be determined from their synthetic ids, or placed in the form as  
hidden fields.

> Another suggestion would be a way to tell a form helper about a  
> hierarchy of objects (or have it intuitively deduce them?). Ideally, it  
> would seem that while the Promo object’s attributes exist in params as  
> promo[title], promo[description] and so forth that its children’s data  
> should exist in params as promo[promo\_questions][id][question\_text] and  
> promo[promo\_questions][id][promo\_answers][id][answer\_text] (where “id”  
> would be replaced by the actual id of the existing object or an empty  
> string for new objects). This should then be able to be passed to  
> @promo.update\_attributes() and @promo.new() alike to create or update  
> all these items in one clean, elegant swoop.

An update\_attributes method that worked hierarchically like this would  
be nice.

–  
We develop, watch us RoR, in numbers too big to ignore.