Forms for multiple records

[MarkMT]

I have a couple of related questions...

What is the merb way to provide forms with fields for multiple
instances of the same model? Rails has the bracket notation and also
the ':index' attribute on input fields, but I'm not having any success
making those work in merb.

The kind of situation I'm looking at is where I have an event
registration form that includes address information for two different
individuals who are part of the registration. Something like this...

form_for @registration do

fields_for @registration.first_person.address do
text_field :street_address
end

fields_for @registration.second_person.address do
text_field :street_address
end

end

So from this I get two sets of POST parameters 'address
[street_address]' , and the second overwrites the first. Obviously not
what I'm aiming for. I've tried a few things but haven't found
anything yet that works.

The second question (perhaps a datamapper question) arises in the same
context...

The Registration model belongs to both the first_person and the
second_person, and both are instances of the User class. So in my
Registration class I tried something like -

class Registration
belongs_to :first_person, :class_name => User
belongs_to :second_person, :class_name => User
end

The problem of course is that I end up with two foreign keys with the
identical name: 'user_id'. What's the right way to deal with this kind
of situation? I tried a ':foreign_key' option, which apparently works
in Rails, but that doesn't seem to help here.

Appreciate any advice.

Mark.

[Tze Yang Ng]

> The second question (perhaps a datamapper question) arises in the same
> context...
>
> The Registration model belongs to both the first_person and the
> second_person, and both are instances of the User class. So in my
> Registration class I tried something like -
>
> class Registration
>  belongs_to :first_person, :class_name => User
>  belongs_to :second_person, :class_name => User
> end
>
> The problem of course is that I end up with two foreign keys with the
> identical name: 'user_id'. What's the right way to deal with this kind
> of situation? I tried a ':foreign_key' option, which apparently works
> in Rails, but that doesn't seem to help here.

U can do the following:

class Registration
belongs_to :first_person, :class_name => User, :child_key =>
[:first_person_id]
belongs_to :second_person, :class_name => User, :child_key =>
[:second_person_id]
end

See http://datamapper.org/doku.php?id=docs:associations

Cheers

--
http://ngty77.blogspot.com

[MarkMT]

Thanks, that successfully solved the second problem. Interesting that
you can specify that from either side of the association.

Still hoping for advice on the first problem...

[MarkMT]

On Mar 20, 9:21 am, MarkMT <mark.thom...@ieee.org> wrote:
>
> What is the merb way to provide forms with fields for multiple
> instances of the same model? Rails has the bracket notation and also
> the ':index' attribute on input fields, but I'm not having any success
> making those work in merb.

After some trawling through code, it appears that merb does not handle
this situation.

I've been looking at the possibility of hacking the form helpers to
insert an index into the name attribute of <input> tags. I think this
can work for existing records, but for new records, where Rails allows
something like form_for 'some_model[]' , it looks like some changes
would also be required somewhere in the request handling process.

Advice still welcome...

[Tze Yang Ng]

> The kind of situation I'm looking at is where I have an event
> registration form that includes address information for two different
> individuals who are part of the registration. Something like this...
>
> form_for @registration do
>
>  fields_for @registration.first_person.address do
>    text_field :street_address
>  end
>
>  fields_for @registration.second_person.address do
>    text_field :street_address
>  end
>
> end
>
> So from this I get two sets of POST parameters 'address
> [street_address]' , and the second overwrites the first. Obviously not
> what I'm aiming for. I've tried a few things but haven't found
> anything yet that works.

Maybe u can try the following:

form_for @registration do

fields_for :first_person_address do
text_field :street_address # , :value =>
@registration.first_person.address.street_address
end

fields_for :second_person_address do
text_field :street_address # , :value =>
@registration.second_person.address.street_address
end

end

The :value is needed if :street_address is editable. U may even need
to throw in a hidden field for :id, depending on ur requirements.

:] TY

--
http://ngty77.blogspot.com

[MarkMT]

Thanks, I'll try that, although I'm pretty sure that the name
attribute in the html input element will be generated from the model's
class, which would be the same for both :first_person_address
and :second_person_address. So (I think) you'll again end up with the
second input overwriting the first.

However, I have made some other progress on this...

Some more examination of the code and a little experimentation reveals
that the request handler in merb does actually accommodate input's
with names like address[first_person][street_address] and address[]
[street_address]. In the first case, params[address] will be a hash
like {"first_person"=>{"street_address" => "..."}, "second_person" =>
{"street_address" => "..."}. In the second case an array is created
like - [{"street_address" => "..."}, {"street_address" => "..."}].
i.e. just like the way Rails works.

In addition, I found that I can create those inputs by specifying the
name of the field explicitly in the tag helper, i.e. like -

<%= text_field :name => "address[first_person][street_address]" %>

This isn't quite as elegant as Rails, since you have to repeat the
model name in each tag statement instead of relying on fields_for or
form_for to provide it. And afaik you can't use the :index option like
you can in Rails. However this is enough to keep me going for now. I
guess we'll get this extra stuff for free when Rails 3.0 arrives, so
probably not a high priority to add these capabilities to Merb at this
point, but it could be done.