MIME-Version: 1.0
Received: by 10.151.112.12 with SMTP id p12mr38266ybm.23.1221589656373; Tue, 
	16 Sep 2008 11:27:36 -0700 (PDT)
Date: Tue, 16 Sep 2008 11:27:36 -0700 (PDT)
In-Reply-To: <eddd257a-8511-4535-ab5b-139705f1ed73@l64g2000hse.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> 
	<99bf9578-0bf5-450c-9221-fa56e7e5cde3@w7g2000hsa.googlegroups.com> 
	<eddd257a-8511-4535-ab5b-139705f1ed73@l64g2000hse.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: <cbf05285-7030-48be-913e-d8f912238553@59g2000hsb.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: quoted-printable

Cool, Dave, nice approach. I added it to the gist.
http://gist.github.com/10793

Out of curiosity, do you have a "new task" link on the form which
dynamically adds new fields using Javascript? Is it difficult to
generate the auto-incrementing number with this?

Regards,

Ryan


On Sep 16, 8:01=A0am, Dave Rothlisberger <droth...@gmail.com> wrote:
> For what it's worth, in my project I've been using something like a
> combination of Approaches 1 & 3 (fromhttp://gist.github.com/10793):
>
> {
> =A0 tasks =3D>
> =A0 =A0 {
> =A0 =A0 =A0 '1' =3D> { :id =3D> '3', :name =3D> 'Foo' },
> =A0 =A0 =A0 '2' =3D> { :name =3D> 'Bar' },
> =A0 =A0 =A0 '3' =3D> { :name =3D> 'Baz' },
> =A0 =A0 }
>
> }
>
> As with Approach 1, you can tell new records from existing records by
> the lack of an :id attribute.
>
> As with Approach 3, this supports nesting associations multiple levels
> deep because it uses a hash rather than arrays.
>
> The keys in the tasks array (1, 2 & 3) come from the counter variable
> created by render :partial, :collection (or from an each_with_index
> loop).
>
> Regards
> Dave.
>
> On Sep 15, 4:43=A0pm, Ryan Bates <r...@railscasts.com> wrote:
>
> > 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 (athttp://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