MIME-Version: 1.0
Received: by 10.100.231.16 with SMTP id d16mr23387anh.20.1221515015887; Mon, 
	15 Sep 2008 14:43:35 -0700 (PDT)
Date: Mon, 15 Sep 2008 14:43:35 -0700 (PDT)
In-Reply-To: <53125740-1a14-48e6-8bb5-ab6a40adc6a2@34g2000hsh.googlegroups.com>
X-IP: 65.163.252.126
References: <33841ac70809101236n5bf8eef9u503ce90d1408d89b@mail.gmail.com> 
	<9212531d0809101250x6f026fe5p26daee71a8d44c67@mail.gmail.com> 
	<33841ac70809101323q605a325fl52d66ce0511eb7e1@mail.gmail.com> 
	<6fff76ee-ec12-46da-a5c5-40b4f5d1364c@i24g2000prf.googlegroups.com> 
	<54398535-5A68-4736-A98E-6907A5DE127F@gmail.com> <3cc7f397-ad17-4122-81f8-3ebeb9f99199@a8g2000prf.googlegroups.com> 
	<97efa336-8fc0-4205-aafc-28e529b6ccd5@y21g2000hsf.googlegroups.com> 
	<53125740-1a14-48e6-8bb5-ab6a40adc6a2@34g2000hsh.googlegroups.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_4; en-us) 
	AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1,gzip(gfe),gzip(gfe)
Message-ID: <99bf9578-0bf5-450c-9221-fa56e7e5cde3@w7g2000hsa.googlegroups.com>
Subject: Re: why revert "adding accessible option to allow for allowing mass 
	assignments"?
From: Ryan Bates <r...@railscasts.com>
To: "Ruby on Rails: Core" <rubyonrails-core@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I've been giving some thought to the interface. One question I keep
coming back to is: how much do we want to support multi-model forms
through this? I think that is the primary use case, but this has other
uses as well. Active Record is not specific to web interfaces and
therefore shouldn't be tied too heavily to them.

IMO Approach 1 (at http://gist.github.com/10793) is the cleanest
approach if we're just doing this all in Ruby. This is also fairly
easy to use in a web form. However, there are a few major drawbacks
when doing so:

1. The resulting HTML is not validatable due to the duplicate form
field names.
2. It's more difficult to work with the fields in Javascript because
of the duplicate form field names.
3. It's impossible to nest associations multiple layers deep because
it gets confused when there are multiple "[]" in the field name.
4. Checkboxes (and I think radio buttons?) are nearly impossible to
get working.

Each of these problems stem from the fact that not each field has a
unique name/identifier. Therefore when it comes to multi-model form
fields, I'm more inclined to go with Approach 3 because each record
has its own unique key/identifier. Theoretically that will solve all
of the problems above.

That said, if you ever need to set associated attributes in other
scenarios (maybe preparing data in test cases), then Approach 3 is not