Lesson 5
Rails Form Processing
To listen to the lesson, click the Play button on the left. You can also right-click on the download link to save the mp3 file, or you can subscribe in iTunes (just search for Learning Rails).
To read a transcript of the lesson, click the Transcript link on the left.
The heart of the lesson is the audio; these notes are supplementary. So please listen to the audio, or read the transcript, before making use of these notes.
Lesson Notes
CRUD is the acronym for the four main things you do with database records:
- Create
- Read
- Update
- Delete
These notes illustrate the code described in the podcast. See the transcript for more details.
For more details about forms processing with Rails, see the forms page in our topics section. You’ll find some great screencasts listed there that will go into much more depth than this podcast.
For a database of podcast episodes, with a title and a description field for each, the basic form code looks like this:
<% form_for @podcast do |form| %>
<%= form.text_field :title %>
<%= form.text_area :description %>
<% end %>
The minimal code for the controller’s create action is:
Podcast.create params[:podcast]
The create method takes the parameters from the params[:podcast] hash, uses them to initialize a new object, and then saves that object to the database.
This line to the podcast model ensures that podcasts can’t be saved with a blank title:
validates_presence_of :title
In the controller, the create action tests the value returned from the Podcast.create call, and if it is not false, it knows the save succeeded. If it is false, then the form is rendered again.
if Podcast.create params[:podcast]
redirect_to (wherever you want to go after a successful save)
else
render :action => :new
end
To display the error messages, the form view just includes a call to the error_messages_for helper:
error_messages_for :podcast
To make this an Ajax form, we can simply change the form_for helper to remote_form_for:
<% remote_form_for @podcast do |form| %>
The rest of the form remains the same. The controller and views must be modified to return just an HTML or JavaScript snipped, rather than an entire page, after a create or update action.
Sponsored By
Reader Comments
24 comments
From: Maxim D, 05/12/10 02:24 PM
Just wanted to point out that error_message_on and error_message_for helpers are depreciated. Here is a ticket which explains why this has been done: https://rails.lighthouseapp.com/projects/8994/tickets/1484-deprecate-error_messages_for.
About submit
From: vvdpzz, 04/09/10 08:16 AM
I am so sorry. My safari did not alert me that I have submit so many times....
About submit
From: vvdpzz, 04/09/10 08:16 AM
I am so sorry. My safari did not alert me that I have submit so many times....
who called create
From: vvdpzz, 04/09/10 08:14 AM
Hi everyone~ Just type: rake routes that you can see : users GET /users(.:format) {:controller=>"users", :action=>"index"} POST /users(.:format) {:controller=>"users", :action=>"create"} So that mean when you POST data rails will call create action. This problem really confuse me a lot of time (:
who called create
From: vvdpzz, 04/09/10 08:14 AM
Hi everyone~ Just type: rake routes that you can see : users GET /users(.:format) {:controller=>"users", :action=>"index"} POST /users(.:format) {:controller=>"users", :action=>"create"} So that mean when you POST data rails will call create action. This problem really confuse me a lot of time (:
who called create
From: vvdpzz, 04/09/10 08:14 AM
Hi everyone~ Just type: rake routes that you can see : users GET /users(.:format) {:controller=>"users", :action=>"index"} POST /users(.:format) {:controller=>"users", :action=>"create"} So that mean when you POST data rails will call create action. This problem really confuse me a lot of time (:
who called create
From: vvdpzz, 04/09/10 08:14 AM
Hi everyone~ Just type: rake routes that you can see : users GET /users(.:format) {:controller=>"users", :action=>"index"} POST /users(.:format) {:controller=>"users", :action=>"create"} So that mean when you POST data rails will call create action. This problem really confuse me a lot of time (:
who called create
From: vvdpzz, 04/09/10 08:14 AM
Hi everyone~ Just type: rake routes that you can see : users GET /users(.:format) {:controller=>"users", :action=>"index"} POST /users(.:format) {:controller=>"users", :action=>"create"} So that mean when you POST data rails will call create action. This problem really confuse me a lot of time (:
who called create
From: vvdpzz, 04/09/10 08:14 AM
Hi everyone~ Just type: rake routes that you can see : users GET /users(.:format) {:controller=>"users", :action=>"index"} POST /users(.:format) {:controller=>"users", :action=>"create"} So that mean when you POST data rails will call create action. This problem really confuse me a lot of time (:
who called create
From: vvdpzz, 04/09/10 08:14 AM
Hi everyone~ Just type: rake routes that you can see : users GET /users(.:format) {:controller=>"users", :action=>"index"} POST /users(.:format) {:controller=>"users", :action=>"create"} So that mean when you POST data rails will call create action. This problem really confuse me a lot of time (:
who called create
From: vvdpzz, 04/09/10 08:14 AM
Hi everyone~ Just type: rake routes that you can see : users GET /users(.:format) {:controller=>"users", :action=>"index"} POST /users(.:format) {:controller=>"users", :action=>"create"} So that mean when you POST data rails will call create action. This problem really confuse me a lot of time (:
who called create
From: vvdpzz, 04/09/10 08:14 AM
Hi everyone~ Just type: rake routes that you can see : users GET /users(.:format) {:controller=>"users", :action=>"index"} POST /users(.:format) {:controller=>"users", :action=>"create"} So that mean when you POST data rails will call create action. This problem really confuse me a lot of time (:
From: vvdpzz, 04/09/10 08:13 AM
Hi everyone~ Just type: rake routes that you can see : users GET /users(.:format) {:controller=>"users", :action=>"index"} POST /users(.:format) {:controller=>"users", :action=>"create"} So that mean when you POST data rails will call create action. This problem really confuse me a lot of time (:
From: vvdpzz, 04/09/10 08:13 AM
Hi everyone~ Just type: rake routes that you can see : users GET /users(.:format) {:controller=>"users", :action=>"index"} POST /users(.:format) {:controller=>"users", :action=>"create"} So that mean when you POST data rails will call create action. This problem really confuse me a lot of time (:
From: vvdpzz, 04/09/10 08:13 AM
Hi everyone~ Just type: rake routes that you can see : users GET /users(.:format) {:controller=>"users", :action=>"index"} POST /users(.:format) {:controller=>"users", :action=>"create"} So that mean when you POST data rails will call create action. This problem really confuse me a lot of time (:
567
From: 767, 02/05/09 12:47 AM
6756
performance
From: Kevin, 11/20/08 05:02 AM
Hi Michael, Thanks for that informative reply,do you think that there will be any support for compiled languages such as c# or another basic compiled language to address this performance issue?
Speed and Crawl impact
From: Michael Slater, 11/19/08 09:41 PM
Kevin, The controller and router approach doesn't hurt SEO at all -- in fact, it is good for it, because you can make the URLs be exactly what you want. As for speed, the performance of a Rails site will typically be a slower than a PHP site, but only if you don't use Rails caching, which effectively delivers static pages most of the time (but it can be a little tricky to set up, depending on the site design). With regard to shared servers, Rails is not a good match for situations in which you run 100s of sites from one server; it does demand more resources. The Passenger module for Apache does allow this sort of setup, and will free up memory when sites are idle, but performance is poor the first time you hit a site that has been kicked out of memory.
Speed and Crawl Impact
From: Kevin Naidoo, 11/19/08 12:45 PM
I am a newbie to ruby on rails so i don't know if this makes sense ,but i have picked two general concerns: Firstly with the whole controller and router concept, does this not mess up SEO? (possibly confuse web crawlers such as googlebots) Secondly i don't understand this concept of "slower speed for faster development cycle" , i am not sure how RoR servers work but in the case of shared hosting for example where you have 100's of web sites utilizing the same server or a high bandwidth site(online gaming) will this not cause a great deal of inefficiency ?
create vs new
From: Ibrahim , 09/27/08 04:23 PM
The difference between create and new is: New means create a new Model instance so that you can manipulate data, but it will not be saved to the database (until you call the save method). Example 1# Open up ruby console (ruby script/console) post = Post.new do |p| p.title = "First post" end # => now it will give you a hash of information that's ready to be send to the database Now it is not saved, but with this line it will: post.save Create does the same as new, it creates a new instance of the Model, but it will also save it to the database. I think the guys here used it because they needed an instance of the Model to build up the form. What I don't get is: why use two methods if it can he handled in just one ?!
Thank you..
From: David Pickens, 05/12/08 01:55 AM
I have studied dozens of tutorials / books, and none of them explained the difference and interplay between new and create. I was shaking my shaggy head for many many hours over this, analyzing restful_authentication, and couldn’t understand what the session new method did (nothing it seemed) and where create was used!
A pretty important basic concept I think. Thank you for helping this n00b! :)
that helps...
From: Steve, 05/07/08 02:23 AM
...a little anyway. :) Seeing ”@podcast=Podcast.new” duplicated in both actions is proving to be hard for me to comprehend. I gather that in the case of “new” that line establishes an intentionally temporary reference (what you call an “empty object”) so that “form_for” knows what “for” is. In the case of the “new” action the @podcast variable is needed to set the key for the hash, right? Because it seems that all “create” needs in order to create and attempt to save the object is the contents of the:podcast hash. I guess my confusion boils down to ”@podcast” being declared in 2 places for different purposes.
Oh – I noticed one small typo in the notes on this page (not the transcript). You have a “has” where you meant “hash” in the line that reads:
“The create method takes the parameters from the params[:podcast] has”
Thanks Michael.
New vs. Create
From: Michael Slater, 05/06/08 02:37 PM
The New action prepares the form for display; the Create action processes the data that was entered and attempts to save it to the database. If it doesn’t succeed, it displays the New form again with the previously entered data and the validation error messages. (One potentially confusing bit of syntax: the line “render :action => :new” renders the view file associated with the new action but does not execute the action itself.) The New action sets up an empty object, whereas the Create action makes an object with the data from the form. When you get to the screencast lessons (starting at lesson 9), you’ll see a full code example which should help clarify this.
new vs. create
From: Steve, 05/06/08 05:58 AM
Can you clarify for me the difference between “new” and “create”? Both actions seem to start off by initialize a new variable (”@podcast=Podcast.new” in this case). “New” just generates the form (and the reference to @podcast), which “Create” then uses to attempt to save to the database using the data in the hash that has been populated by the form set up by “New”? I’ve read a bunch of stuff and watched a bunch of stuff and I still don’t feel I have a grasp of the interplay between new and create. Thanks!