The whole thing is pretty simple.

<% form_for :student, @student,
      :url => student_url(:action=>'update') do |f| %>
  <ul>
    <li>Name: <%= f.text_field(:name) %></li>
    <li>Age: <%= f.text_field(:age,:size=>2) %></li>
  </ul>
  <%= submit_tag "Save" %>
<% end %>

Some observations:

• Anything in the block is contained in the resulting form tag (no chance you’ll forget it)
• Unlike the plain text_field helper (and others) you’d have to pass in a symbol (and would expect a similarly named instance variable in scope), you can give the form_for any object you’d like, named anything you’d like, and any field method called on the form object will name the field correctly and use the existing attribute for its value.
• You pass :url to remote_form_for as well, meaning there’s less chance you’ll forget what API to use for which method, and that’s good thing.

There’s a lot more to talk about here, including fields_for and form builders (which are worth a post all by themselves), but I think you get the point.

Reference: form_helper.rb in a fresh edge rails checkout.

In the beginning (or nearly so), we had form_tag and end_form_tag. Now, these were still better than typing <form> and </form>, and trying to throw in form attributes, but they really didn’t even begin to use the full power of what Ruby (and ERB) had to offer.

A while back, form_for (and it’s sexy friend remote_form_for) came on the scene, but a lot of people haven’t noticed. These are cleaner, more elegant, and more flexible ways of making both regular and remote forms, and you should be using them.