Form with subforms

rubyonrails-talk
1

Hi,

I'm looking for a way to implement subforms. For example, a form where you can add clients, and at the same time enter contactpersons for this client.

I've been looking around, reading ebooks, etc, but can't seem to find a good example/tutorial for something like this. So I would be very thankful if someone could point me in the right direction.

Thanks,

Sven

2

Hi Sven,

Sven Magnus wrote:

I'm looking for a way to implement subforms. For example, a form where you can add clients, and at the same time enter contactpersons for this client.

The specs don't allow for forms within forms. But you can have more than one form on a page.

The challenge is to structure things so that the page only submits, from an end-user perspective, when you want it to. So you'll probably end up with a mix of form_tag or form_for that submit via HTTP, and other forms that submit via XMLHttpRequest in the background. Depending how how 'fancy' you want your UI, you'll probably end up using observers on fields like checkboxes to trigger the rendering of new forms on the page. I'd recommend picking up a copy of Cody Fauser's "RJS Tutorial" at O'Reilly. I did and found it was $10 well spent.

hth, Bill

3

Thanks for your reply. I'll look into it.

Are you talking about "RJS Templates for Rails"?

Thanks,

Sven

4

Hi Sven,

Sven Magnus wrote:

Are you talking about "RJS Templates for Rails"?

That's the one. Best $10 I've spent so far learning Rails.

Best regards, Bill

5

So, is this approach any good?

- Store the new "item" in a session variable - Create two diffferent forms on the same page, one for adding the item and one for adding the subitems using Ajax - The subitem form will add new subitems to the item stored in the session

Is that how this kind of thing should/coul be done?

Thanks,

Sven

6

You’ll need to be careful using the two forms with an Ajax implementation on one. Sometimes a user might have JS off and then will submit in ways you might not be prepared for.

RSL

7

Hi Sven,

Sven Magnus wrote:

So, is this approach any good?

As Russel notes, you need to recognize that some users may not have js enabled and deal with that somehow. How you do it really depends on your business model. More on that below.

- Store the new "item" in a session variable

It's early here and I don't have a threaded email reader so I don't know if there was something in your previous post that would drive storing the item in a session variable. The choice between storing items in session variables and in the database depends on too many things to give advice on without more info.

- Create two diffferent forms on the same page, one for adding the item and one for adding the subitems using Ajax - The subitem form will add new subitems to the item stored in the session

Is that how this kind of thing should/coul be done?

The general model would be to first render the main form for adding items. That form could have an element on it that would trigger the rendering of the second form. So maybe there's a checkbox labeled 'add sub-items' next to an item on the main form. You put an observe_field on that checkbox. In your design thinking, you have to figure out how you're going to handle the transaction in both js-enabled and js-disabled states. Here's one, still-working-on-my-first-cup-of-java approach.

If the user has js enabled, when they check the checkbox it will trigger a method in the controller which uses RJS to render the sub-form immediately. So if they've got js-enabled they'll go ahead and add sub-items before submitting the main form. If the user doesn't have js enabled, the observer won't do anything. When the main form is submitted, you check the value of the checkbox. If it's checked, you check to see if you have any sub-items. If you do, you assume they have js-enabled, that they're done with that, and take them to the next step in the process. If you don't, you assume they have js-disabled and take them to an interim page where they can enter the sub-items.

The respond_to method can let you know very early in the user's visit whether or not they have js-enabled. This gives you the ability to plan entirely different 'routes' through the app. Or you can take an approach like the above. Or you can, depending on your business model, decide not to allow the use of the site by js-disabled browsers. All, and more, are valid choices. It's important to make that decision explicitly so you can communicate it if needed to your visitors.

hth, Bil