belongs-to association multi-form stuff

[Francis Hwang]

Dear fellow admin_assistant users,

I'm thinking of taking on subforms in some way in admin_assistant.
When, say, you're creating a Product and would also like to create a
Product Category at the same time. I know that ActiveScaffold does
some sort of association subform thing, but I've held off on doing a
straight-on clone of that functionality, because I'd like to get a
sense of what people would actually specifically want out of such a
feature. Back when I was using ActiveScaffold I'd actually skipped
doing the subform stuff, so I don't have much of an opinion.

So, did AS handle subforms well? Does the new subforms stuff in Rails
2.3 work with the way you guys might like to do it? What have people's
experiences been like?

Francis

[Mike Dalessio]

I personally like how Rails 2.3 handles nested attributes and forms. If you were going to simply leverage that (meaning the subforms wouldn't be available for earlier Rails versions), I think it would be straightforward to implement.

I would guess that supporting earlier versions is likely to be hairy.

--
mike dalessio
mi...@csa.net

[Francis Hwang]

Yeah, I spent a bit looking into the new Rails 2.3 nested forms stuff.
I haven't played with them, but I'm feeling a bit lukewarm towards
them. This blog post makes sense to me: It seems invasive and
excessive to be defining these sort of nesting relationships on the
model, instead of in the controller. What do you think?

http://blog.smartlogicsolutions.com/2009/02/24/rails-23-nested-object-forms-im-not-crazy-about-them/

Francis

[Mike Dalessio]

Yup, I read that, too. However, as someone who's on a project that had to hand-code nested associations a dozen times before 2.3 came out, I think that there's a significant developer-resource win with using them, even if they're not totally perfect.

And, there are situations where you'd want this logic in the model (and others where it would be better in the controller) -- it's not an outlandish assumption to have been made by rails-core.

--
mike dalessio
mi...@csa.net

[Francis Hwang]

Mike, what sort of situations would make this a good fit in the model?
I haven't actually tried to use any nested associations heavily yet,
and I'm trying to wrap my head around the tradeoffs.

FH

[Mike Dalessio]

The naive scenario is:

class Person < ActiveRecord::Base
  has_many :phone_numbers
  accepts_nested_attributes_for :phone_numbers, :allow_destroy => true
end

I can build a form partial that allows me to add or delete phone numbers from a person, and use it anywhere I want, without having to explicitly allow it from the controller.

Maybe this is no big deal for people with time on their hands, but I've found that:

a) Writing the model code by hand to handle magic attributes like phone_numbers_attributes is extremely error-prone and time consuming to get right, especially in edge cases with failing validations and re-rendering of the form

b) The obvious default for a nested attribute like phone_numbers is ALLOW. If I was forced to explicitly declare that I wanted to allow it in the controller, I wouldn't mind, but I certainly don't miss it, either.

c) In the cases where Person is editable all over the site (as a nested resource itself, no less), this is a huge win. I can have reports with authors, allegations with victims and perpetrators, groups with members, tasks with assignees, etc. All of these can nest person, and then automatically get phone numbers as well.

YMMV, and security is certainly a concern, as pointed out in the post you referenced. But I've found that there is more win than potential lose with the nested attributes.

--
mike dalessio
mi...@csa.net

[Francis Hwang]

Yeah, I suppose part of what makes that a win for that use case is
that PhoneNumber is tightly bound to Person; a PhoneNumber record
without a corresponding Person isn't going to make much sense. So,
accordingly, anybody in a position to edit a Person record should also
be able to add/edit/delete PhoneNumbers.

As opposed to, say:

class ProductCategory < ActiveRecord::Base
has_many :products
accepts_nested_attributes_for :products, :allow_destroy => true
end

... a scenario where the Product is actually way more important than
the ProductCategory, and having a Product without a ProductCategory is
possibly quite useful.

For me, I actually don't have a specific security concern with it,
especially since most of the sites I work on don't have a very fine-
grained ACL: If you can edit one object in the DB you can edit almost
all of them, so making the distinction maybe isn't that useful. I
guess I'm just leery of making changes in the models of very big
sites, but I can't think of specific problems this would cause off the
top of my head ... maybe I should just get over it.

Francis Hwang
http://fhwang.net/

[Mike Dalessio]

On Tue, Sep 22, 2009 at 8:51 AM, Francis Hwang <se...@fhwang.net> wrote:

Yeah, I suppose part of what makes that a win for that use case is
that PhoneNumber is tightly bound to Person; a PhoneNumber record
without a corresponding Person isn't going to make much sense. So,
accordingly, anybody in a position to edit a Person record should also
be able to add/edit/delete PhoneNumbers.

As opposed to, say:

class ProductCategory < ActiveRecord::Base
  has_many :products
  accepts_nested_attributes_for :products, :allow_destroy => true
end

... a scenario where the Product is actually way more important than
the ProductCategory, and having a Product without a ProductCategory is
possibly quite useful.

For me, I actually don't have a specific security concern with it,
especially since most of the sites I work on don't have a very fine-
grained ACL: If you can edit one object in the DB you can edit almost
all of them, so making the distinction maybe isn't that useful. I
guess I'm just leery of making changes in the models of very big
sites, but I can't think of specific problems this would cause off the
top of my head ... maybe I should just get over it.

Yeah, my (and my team's) opinion is generally, that we save time not writing magic attribute setters so that we can afford to spend some time on model security to make it tight.

And, in general, if you have a case (like the one the article uses as a straw man) where a model like Credit is something that should clearly be permissioned completely differently from the parent resource, then maybe that's not a good candidate for using nested attributes.

 

--
mike dalessio
mi...@csa.net

[Collin Miller]

To throw another opinion in the ring...

I feel that having good, useable, and error-resistant nested object
creation code is a good thing.

But I feel the way Rails 2.3 did it is imperfect.

I have built applications where creating multiple objects with one
form made sense. I wanted to enforce that a user supply this data in
order to submit the form. It made the most sense for the user to enter
all the data, but the app wouldn't break if saved without them. I
prefer to keep a minimum number of hard validations in the model
layer.

I also appreciate the case for putting this in a model and being able
to validate it at that layer (especially for cases such as phone
numbers.)

So, I am in the camp that we should have both. And put this in the
model when we need it for data integrity, and the controller when our
work-flow dictates.

I like to get my rails apps to the point where the model layer is
fairly solid, so I can have confidence in quickly re-factoring the
controllers and views to facilitate quick changes in work-flow. Having
the choice of Model vs Controller would be super awesome at that
point.

And it seems that, if well made, the AR code(haven't look at it, I'm a
DataMapper fan now) should be a good starting point facilitate both of
these needs.

Hmm, didn't directly answer the question, but those are my thoughts on
the matter.

On Sep 22, 9:35 am, Mike Dalessio <mike.dales...@gmail.com> wrote:

> > > On Mon, Sep 21, 2009 at 10:16 AM, Francis Hwang <s...@fhwang.net>

> > > wrote:
>
> > > Mike, what sort of situations would make this a good fit in the model?
> > > I haven't actually tried to use any nested associations heavily yet,
> > > and I'm trying to wrap my head around the tradeoffs.
>
> > > FH
>

> > > On Fri, Sep 18, 2009 at 4:33 PM, Mike Dalessio <mike.dales...@gmail.com

> > > > wrote:
> > > > Yup, I read that, too. However, as someone who's on a project that
> > > had to
> > > > hand-code nested associations a dozen times before 2.3 came out, I
> > > think
> > > > that there's a significant developer-resource win with using them,
> > > even if
> > > > they're not totally perfect.
> > > > And, there are situations where you'd want this logic in the model
> > > (and
> > > > others where it would be better in the controller) -- it's not an
> > > outlandish
> > > > assumption to have been made by rails-core.
>

> > > > On Fri, Sep 18, 2009 at 3:53 PM, Francis Hwang <s...@fhwang.net>

> > > wrote:
>
> > > >> Yeah, I spent a bit looking into the new Rails 2.3 nested forms
> > > stuff.
> > > >> I haven't played with them, but I'm feeling a bit lukewarm towards
> > > >> them. This blog post makes sense to me: It seems invasive and
> > > >> excessive to be defining these sort of nesting relationships on the
> > > >> model, instead of in the controller. What do you think?
>

> >http://blog.smartlogicsolutions.com/2009/02/24/rails-23-nested-object...

>
> > > >> Francis
>
> > > >> On Fri, Sep 18, 2009 at 2:35 PM, Mike Dalessio <

> > mike.dales...@gmail.com

> > > >> > m...@csa.net
>
> > > > --
> > > > mike dalessio
> > > > m...@csa.net
>
> > > --
> > > mike dalessio
> > > m...@csa.net
>
> --
> mike dalessio
> m...@csa.net

[Francis Hwang]

Thanks for the input. It sounds like Rails 2.3 nested forms is
imperfect, as you say, but useful enough that it's worth integrating
into AA. It won't be the only way to solve these problems, but should
probably be a good tool in the toolbelt.

Francis Hwang
http://fhwang.net/