rails file_field/form_for

 see the  api:

file_field(object_name, method, options = {})

Returns an file upload input tag tailored for accessing a specified attribute (identified by method) on an object assigned to the template (identified by object). Additional options on the input tag can be passed as a hash with options. These options will be tagged onto the HTML as an HTML element attribute as in the example shown.

Examples

  file_field(:user, :avatar)
  # => <input type="file" id="user_avatar" name="user[avatar]" />

  file_field(:post, :attached, :accept => 'text/html')
  # => <input type="file" id="post_attached" name="post[attached]" />

  file_field(:attachment, :file, :class => 'file_input')
  # => <input type="file" id="attachment_file" name="attachment[file]" class="file_input" />

[ show source ]

     # File vendor/rails/actionpack/lib/action_view/helpers/form_helper.rb, line 347
347:       def file_field(object_name, method, options = {})
348:         InstanceTag.new(object_name, method, self, nil, options.delete(:object)).to_input_field_tag("file", options)
349:       end

form_for(record_or_name_or_array, *args, &proc)

Creates a form and a scope around a specific model object that is used as a base for questioning about values for the fields.

  <% form_for :person, @person, :url => { :action => "update" } do |f| %>
    First name: <%= f.text_field :first_name %>
    Last name : <%= f.text_field :last_name %>
    Biography : <%= f.text_area :biography %>
    Admin?    : <%= f.check_box :admin %>
  <% end %>

Worth noting is that the form_for tag is called in a ERb evaluation block, not an ERb output block. So that‘s <% %>, not <%= %>. Also worth noting is that form_for yields a form_builder object, in this example as f, which emulates the API for the stand-alone FormHelper methods, but without the object name. So instead of text_field :person, :name, you get away with f.text_field :name.

Even further, the form_for method allows you to more easily escape the instance variable convention. So while the stand-alone approach would require text_field :person, :name, :object => person to work with local variables instead of instance ones, the form_for calls remain the same. You simply declare once with :person, person and all subsequent field calls save :person and :object => person.

Also note that form_for doesn‘t create an exclusive scope. It‘s still possible to use both the stand-alone FormHelper methods and methods from FormTagHelper. For example:

  <% form_for :person, @person, :url => { :action => "update" } do |f| %>
    First name: <%= f.text_field :first_name %>
    Last name : <%= f.text_field :last_name %>
    Biography : <%= text_area :person, :biography %>
    Admin?    : <%= check_box_tag "person[admin]", @person.company.admin? %>
  <% end %>

Note: This also works for the methods in FormOptionHelper and DateHelper that are designed to work with an object as base, like FormOptionHelper#collection_select and DateHelper#datetime_select.

HTML attributes for the form tag can be given as :html => {…}. For example:

  <% form_for :person, @person, :html => {:id => 'person_form'} do |f| %>
    ...
  <% end %>

The above form will then have the id attribute with the value </tt>person_form</tt>, which you can then style with CSS or manipulate with JavaScript.

_____________________________________________________