Form override oddities: helper vs. partial

[David C]

When setting up a form override, I started with partial overrides and
all was good as long as the text being entered consisted of single
words with alphanumeric characters. However, upon entering non-
alphanumeric characters, I noticed that URL encoding gets applied to
the input data, e.g., "Foo Bar" becomes "Foo%20Bar".

If I change to using a helper override instead, no URL encoding is
applied to the input data.

In both cases, the override is a simple text_field. The partial
override looks like

<label for="record_name"><%= column.label -%></label>
<%= text_field 'record', 'name', { :class => 'text-input', :size =>
40, :maxlength => 80 } %>

while the helper override looks like

def name_form_column(record, input_name)
text_field :record, :name, { :name => input_name, :class => 'text-
input', :size => 40, :maxlength => 80 }
end

Does anyone have any idea what's happening? In this particular case,
there's no reason not to use a helper override, but I'd like to know
what's going on, or what I'm doing wrong with the partial override, in
case I do find myself in a position where I need to use a partial
override.

[Lance Ivy]

So the difference is in how the data gets submitted? Or displayed?

[David C]

The difference is in the submission of the data. Of course, once it's
stored in the encoded format, it's also displayed the same way.

>From the log:

Processing FooController#create (for 127.0.0.1 at 2007-06-14 16:23:21)
[POST]
Session ID: 22211d130d85d2e0d8a84686733e84d6
Parameters: {"commit"=>"Create", "action"=>"create",
"controller"=>"foo", "record"=>{"name"=>"Foo%20Bar"}}

On Jun 14, 4:10 pm, "Lance Ivy" <l...@cainlevy.net> wrote:
> So the difference is in how the data gets submitted? Or displayed?
>

[Lance Ivy]

Very odd. Hmm, so what's the difference in the *generated* HTML?

On 6/14/07, David C <ot...@crunchyfrog.net > wrote:

[David C]

There's no difference in the generated HTML.

One thing I failed to mention, is that a foo has_many bars. If foo
does not have_many bars, there's no problem.

Very strange indeed.

On Jun 14, 4:35 pm, "Lance Ivy" <l...@cainlevy.net> wrote:
> Very odd. Hmm, so what's the difference in the *generated* HTML?
>

[David C]

Oops, I didn't look deep enough. The input field for the nested form
is different, though I'm not sure why this should affect how the data
from the parent is stored.

Using a helper override, I have

<input id="record_name" class="text-input" type="text" size="40"
name="record[bar][1181866756682][name]" maxlength="80"/>

while using a partial override, I have

<input id="record_name" class="text-input" type="text" size="40"
name="record[name]" maxlength="80"/>

[Lance Ivy]

huh. and those are saving to the same place? one looks like it's saving to the 'name' of the main record, and the other looks like it's saving to the 'name' of a new associated record.

On 6/14/07, David C <ot...@crunchyfrog.net> wrote:

[Dean]

I just discovered that I have a VERY similar problem with a form
override.

If i try to set the name of a field in the override to match whats
generated, it seems to ignore it. For example if tree has many
branches (via tree_id on the branch table, the generated code puts the
name of the field as field[tree][id]. If i put the name as :name
=>"field[tree][id]", it ends up in the generated html as
field[tree]... I don't know how the [id] part of the text gets lost??

Dean

On Jun 14, 7:30 pm, "Lance Ivy" <l...@cainlevy.net> wrote:
> huh. and those are saving to the same place? one looks like it's saving to
> the 'name' of the main record, and the other looks like it's saving to the
> 'name' of a new associated record.
>

[Lance Ivy]

Maybe :name isn't a recognized option for some Rails helpers?

[Dean]

But name is there in the base code in AS for the select box, and
coming out as coded??

On Jun 14, 9:07 pm, "Lance Ivy" <l...@cainlevy.net> wrote:
> Maybe :name isn't a recognized option for some Rails helpers?
>

[David C]

Yes, it looks rather odd, but those two input tags are both from the
associated record's 'name' input field.

The problem only seems to happen if both the parent and child have
columns named 'name' -- change either one to something else and the
problem goes away. (I don't know why I didn't think to try renaming
the columns earlier.)

I reworked my test case and came up with the following, which still
shows the problem.

The models:

class Foo < ActiveRecord::Base
has_many :bars
end
class Bar < ActiveRecord::Base
belongs_to :foo
end

The controllers:

class FoosController < ApplicationController
active_scaffold :foo
end
class BarsController < ApplicationController
active_scaffold :bar
end

The migration:

class CreateFooBars < ActiveRecord::Migration
def self.up
create_table :foos do |t|
t.column :name, :string, :limit => 80, :null => false
end
create_table :bars do |t|
t.column :name, :string, :limit => 60, :null => false
t.column :foo_id, :integer, :null => false
end
end
def self.down
drop_table :bars
drop_table :foos
end
end

The partial that causes the problem (app/views/foos/
_name_form_column.rhtml):

<dl>
<dt>

<label for="record_name"><%= column.label -%></label>

</dt>
<dd>

<%= text_field 'record', 'name', { :class => 'text-input', :size
=> 40, :maxlength => 80 } %>

</dd>
</dl>

The helper that works:

module FoosHelper

def name_form_column(record, input_name)
text_field :record, :name, { :name => input_name, :class => 'text-
input', :size => 40, :maxlength => 80 }
end

end

The problem occurs with both 1.0.1 and the current trunk (r530).

I think I'll stick to avoiding the use of the more generic 'name'
columns in my tables/models. 'foo_name' and 'bar_name' are probably
more meaningful anyway.

On Jun 14, 5:30 pm, "Lance Ivy" <l...@cainlevy.net> wrote:
> huh. and those are saving to the same place? one looks like it's saving to
> the 'name' of the main record, and the other looks like it's saving to the
> 'name' of a new associated record.
>