aboutsummaryrefslogtreecommitdiffstats
path: root/railties/doc/guides/source
diff options
context:
space:
mode:
authorFrederick Cheung <frederick.cheung@gmail.com>2009-01-26 20:45:32 +0000
committerFrederick Cheung <frederick.cheung@gmail.com>2009-01-26 20:45:32 +0000
commit94fde8c63439bc86265fadbd293dbd28b808d830 (patch)
tree293f960735af5a71c2a2f139fe0739576b7b8482 /railties/doc/guides/source
parentd28045fd87026ddf514ed8d9296e9239ff88aab6 (diff)
downloadrails-94fde8c63439bc86265fadbd293dbd28b808d830.tar.gz
rails-94fde8c63439bc86265fadbd293dbd28b808d830.tar.bz2
rails-94fde8c63439bc86265fadbd293dbd28b808d830.zip
more corrections
Diffstat (limited to 'railties/doc/guides/source')
-rw-r--r--railties/doc/guides/source/form_helpers.txt6
1 files changed, 3 insertions, 3 deletions
diff --git a/railties/doc/guides/source/form_helpers.txt b/railties/doc/guides/source/form_helpers.txt
index f48b40c0ab..e2afcf41ba 100644
--- a/railties/doc/guides/source/form_helpers.txt
+++ b/railties/doc/guides/source/form_helpers.txt
@@ -640,7 +640,7 @@ Understanding Parameter Naming Conventions
As you've seen in the previous sections, values from forms can be at the top level of the `params` hash or nested in another hash. For example in a standard `create`
action for a Person model, `params[:model]` would usually be a hash of all the attributes for the person to create. The `params` hash can also contain arrays, arrays of hashes and so on.
-Fundamentally HTML forms don't know about any sort of structured data, all they generate is name-value pairs. The arrays and hashes you see in your application are the result of some parameter naming conventions that Rails uses.
+Fundamentally HTML forms don't know about any sort of structured data, all they generate is name-value pairs, where pairs are just plain strings. The arrays and hashes you see in your application are the result of some parameter naming conventions that Rails uses.
[TIP]
========================
@@ -727,7 +727,7 @@ This will result in a `params` hash that looks like
{'person' => {'name' => 'Bob', 'address' => {'23' => {'city' => 'Paris'}, '45' => {'city' => 'London'}}}}
--------
-Rails knows that all these inputs should be part of the person hash because you called `fields_for` on the first form builder. By specifying an `:index` option you're telling rails that instead of naming the inputs `person[address][city]` it should insert that index surrounded by [] between the address and the city. If you pass an Active Record object as we did then Rails will call `to_param` on it, which by default returns the database id. This is often useful as it is then easy to locate which Address record should be modified. You can pass numbers with some other significance, strings or even nil (which will result in an array parameter being created).
+Rails knows that all these inputs should be part of the person hash because you called `fields_for` on the first form builder. By specifying an `:index` option you're telling rails that instead of naming the inputs `person[address][city]` it should insert that index surrounded by [] between the address and the city. If you pass an Active Record object as we did then Rails will call `to_param` on it, which by default returns the database id. This is often useful as it is then easy to locate which Address record should be modified. You can pass numbers with some other significance, strings or even `nil` (which will result in an array parameter being created).
To create more intricate nestings, you can specify the first part of the input name (`person[address]` in the previous example) explicitly, for example
--------
@@ -752,7 +752,7 @@ produces exactly the same output as the previous example.
Building Complex forms
----------------------
-Many apps grow beyond simple forms editing a single object. For example when creating a Person you might want to allow the user to (on the same form) create multiple address records (home, work etc.). When later editing that person the user should be able to add, remove or amend addresses as necessary. While this guide has shown you all the pieces necessary to handle this, Rails does not yet have a standard end-to-end way of accomplishing this, but many have come up with viable approaches. These include:
+Many apps grow beyond simple forms editing a single object. For example when creating a Person you might want to allow the user to (on the same form) create multiple address records (home, work, etc.). When later editing that person the user should be able to add, remove or amend addresses as necessary. While this guide has shown you all the pieces necessary to handle this, Rails does not yet have a standard end-to-end way of accomplishing this, but many have come up with viable approaches. These include:
* Ryan Bates' series of railscasts on http://railscasts.com/episodes/75[complex forms]
* Handle Multiple Models in One Form from http://media.pragprog.com/titles/fr_arr/multiple_models_one_form.pdf[Advanced Rails Recipes]