I also wrote the accompanying HTML output I expected, favoring something very similar to the fieldsets, lists and other semantic elements Aaron Gustafson presented in Learning to Love Forms, hacking together enough Ruby to prove it could be done.

It’s better than SomeOtherFormBuilder because…

it can handle belongs_to associations (like Post belongs_to :author), rendering a select or set of radio inputs with choices from the parent model.

it can handle has_many and has_and_belongs_to_many associations (like: Post has_many :tags), rendering a multi-select with choices from the child models.

it’s Rails 2.x and 3.x compatible (including nested forms).

it has internationalization (I18n)!

it’s really quick to get started with a basic form in place (4 lines), then go back to add in more detail if you need it.

there’s heaps of elements, id and class attributes for you to hook in your CSS and JS.

Stylesheets

A proof-of-concept stylesheet is provided which you can include in your layout. Customization is best achieved by overriding these styles in an additional stylesheet so that the Formtastic styles can be updated without clobbering your changes. If you want to use these stylesheets, add both to your layout with this helper:

<head>
...
<%= formtastic_stylesheet_link_tag %>
...
</head>

Syntax

Please note: Formtastic makes use of a lot of ERB blocks and currently supports both Rails 2 and Rails 3, which means the syntax in these examples will differ depending on which version of Rails you’re using.

The difference is subtle, with most blocks in Rails 3 requiring the addition of an equals sign:

<!-- Rails 2 -->
<% semantic_form_for @user do |form| %>
<% form.inputs do %>
...
<% end %>
<% end %>
<!-- Rails 3 -->
<%= semantic_form_for @user do |form| %>
<%= form.inputs do %>
...
<% end %>
<% end %>
This README is currently documenting the Rails 2 way only. If you're using Rails 3 and your forms aren't rendering everything as expected, try changing @<%@ to @<%=@.
h2. Usage
Forms are really boring to code... you want to get onto the good stuff as fast as possible.
This renders a set of inputs (one for _most_ columns in the database table, and one for each ActiveRecord @belongs_to@-association), followed by a submit button:
<pre>
<% semantic_form_for @user do |form| %>
<%= form.inputs %>
<%= form.buttons %>
<% end %>

This is a great way to get something up fast, but like scaffolding, it’s not recommended for production.

You probably want to specify the order of the fields, skip some of the fields or even add in fields that Formtastic couldn’t detect, you can pass in a list of field names to inputs and list of button names to buttons:

You probably want control over the input type Formtastic uses for each field, you can expand the inputs and buttons blocks. This specifies the :section input should be a set of radio buttons (rather than the default select box), and that the :created_at field should be a string (rather than the default datetime selects):

If you have more than one form on the same page, it may lead to HTML invalidation because of the way HTML element id attributes are assigned. You can provide
a namespace for your form to ensure uniqueness of id attributes on form elements. The namespace attribute will be prefixed with underscore on the generate html id. For example:

Customize HTML attributes for any input using the :input_html option. Typically this is used to disable the input, change the size of a text field, change the rows in a textarea, or even to add a special class to an input to attach special behavior like autogrow textareas:

Customize the HTML attributes for the <li> wrapper around every input with the :wrapper_html option hash. There’s one special key in the hash (:class), which will actually append your string of classes to the existing classes provided by Formtastic (like "required string error").

Many inputs provide a collection of options to choose from (like :select, :radio, :check_boxes, :boolean). In many cases, Formtastic can find choices through the model associations, but if you want to use your own set of choices, the :collection option is what you want. You can pass in an Array of objects, an array of Strings, a Hash… Throw almost anything at it! Examples:

:country – a select menu of country names. Default for column types: :string with name "country" – requires a country_select plugin to be installed.

:email – a text field (just like string). Default for columns with name matching "email". New in HTML5. Works on some mobile browsers already.

:url – a text field (just like string). Default for columns with name matching "url". New in HTML5. Works on some mobile browsers already.

:phone – a text field (just like string). Default for columns with name matching "phone" or "fax". New in HTML5.

:search – a text field (just like string). Default for columns with name matching "search". New in HTML5. Works on Safari.

:hidden – a hidden field. Creates a hidden field (added for compatibility).

The comments in the code are pretty good for each of these (what it does, what the output is, what the options are, etc.) so go check it out.

Delegation for label lookups

Formtastic decides which label to use in the following order:

1. :label # :label => "Choose Title"
2. Formtastic i18n # if either :label => true || i18n_lookups_by_default = true (see Internationalization)
3. Activerecord i18n # if localization file found for the given attribute
4. label_str_method # if nothing provided this defaults to :humanize but can be set to a custom method

Internationalization (I18n)

Basic Localization

Formtastic got some neat I18n-features. ActiveRecord object names and attributes are, by default, taken from calling @object.human_name and @object.human_attribute_name(attr) respectively. There are a few words specific to Formtastic that can be translated. See lib/locale/en.yml for more information.

Note: This is perfectly fine if you just want your labels/attributes and/or models to be translated using ActiveRecord I18n attribute translations, and you don’t use input hints and legends. But what if you do? And what if you don’t want same labels in all forms?

Enhanced Localization (Formtastic I18n API)

Formtastic supports localized labels, hints, legends, actions using the I18n API for more advanced usage. Your forms can now be DRYer and more flexible than ever, and still fully localized. This is how:

Note: Slightly different because Formtastic can’t guess how you group fields in a form. Legend text can be set with first (as in the sample below) specified value, or :name/:title options – depending on what flavor is preferred.

Semantic errors

ValidationReflection plugin

If you have the ValidationReflection plugin installed, you won’t have to specify the :required option (it checks the validations on the model instead).

Configuration

Run rails generate formtastic:install (Rails 3) or ./script/generate formtastic (Rails 2) to copy a commented out config file into config/initializers/formtastic.rb. You can view the configuration file on GitHub

Form Generator

There’s a Formtastic form code generator to make your transition to Formtastic easier. All you have to do is to specify an existing model name, and optionally specify view template framework (ERB/HAML), and you are good to go. Note: This won’t overwrite any of your stuff.

Basic usage

Rails 3:

$ rails generate formtastic:form ModelName

Rails 2:

$ ./script/generate form ModelName

The results are something like this, with the ERB code printed out to the terminal

Specifying controller namespace with --controller

Custom Inputs

If you want to add your own input types to encapsulate your own logic or interface patterns, you can do so by subclassing SemanticFormBuilder and configuring Formtastic to use your custom builder class.

Formtastic::SemanticFormHelper.builder = MyCustomBuilder

Be aware that you should either set the options on custom builder or require it after setting options on formtastic default builder.

Security

By default formtastic escapes html entities in both labels and hints unless a string is marked as html_safe. If you are using an older rails version which doesn’t know html_safe, or you want to globally turn this feature off, you can set the following in your initializer:

Compatibility

We’re only testing Formtastic with the latest Rails 2.x and 3.x stable releases. Patches are welcome to allow backwards compatibility with older versions of Rails, of course.

Formtastic, much like Rails 2, is very ActiveRecord-centric. Many people are using Formtastic (especially the rails3 branch) successfully with other ActiveModel-like ORMs and classes (DataMapper, MongoMapper, Mongoid, Authlogic, Devise…) but we’re not guaranteeing anything at this stage. Patches are welcome, but it’s not our core focus right now.

How to contribute

Please ensure that you provide appropriate spec/test coverage and ensure the documentation is up-to-date. Bonus points if you perform your changes in a clean topic branch rather than master, and if you create an issue on GH for us to discuss your changes. Pull requests tend to get lost.

Please also keep your commits atomic so that they are more likely to apply cleanly. That means that each commit should contain the smallest possible logical change. Don’t commit two features at once, don’t update the gemspec at the same time you add a feature, don’t fix a whole bunch of whitespace in a file at the same time you change a few lines, etc, etc.

For significant changes, you may wish to discuss your idea on the Formtastic Google group before coding to ensure that your change is likely to be accepted. Formtastic relies heavily on i18n, so if you’re unsure of the impact this has on your changes, please discuss them with the group.