Module: Formtastic::Helpers::InputHelper
- Includes:
- FileColumnDetection, Reflection
- Included in:
- FormBuilder
- Defined in:
- lib/formtastic/helpers/input_helper.rb
Overview
#input is used to render all content (labels, form widgets, error messages, hints, etc) for a single form input (or field), usually representing a single method or attribute on the form’s object or model.
The content is wrapped in an ‘<li>` tag, so it’s usually called inside an inputs block (which renders an ‘<ol>` inside a `<fieldset>`), which should be inside a `semantic_form_for` block:
<%= semantic_form_for @post do |f| %>
<%= f.inputs do %>
<%= f.input :title %>
<%= f.input :body %>
<% end %>
<% end %>
The HTML output will be something like:
<form class="formtastic" method="post" action="...">
<fieldset>
<ol>
<li class="string required" id="post_title_input">
...
</li>
<li class="text required" id="post_body_input">
...
</li>
</ol>
</fieldset>
</form>
Instance Method Summary collapse
-
#input(method, options = {}) ⇒ Object
Returns a chunk of HTML markup for a given ‘method` on the form object, wrapped in an `<li>` wrapper tag with appropriate `class` and `id` attribute hooks for CSS and JS.
Methods included from FileColumnDetection
Methods included from Reflection
Instance Method Details
#input(method, options = {}) ⇒ Object
document the “guessing” of input style
Can we kill ‘:hint_class` & `:error_class`? What’s the use case for input-by-input? Shift to config or burn!
Can we kill ‘:group_by` & `:group_label_method`? Should be done with :collection => grouped_options_for_select(…)
Can we kill ‘:find_options`? Should be done with MyModel.some_scope.where(…).order(…).whatever_scope
Can we kill ‘:label`, `:hint` & `:prompt`? All strings could be shifted to i18n!
Many many more examples. Some of the detail probably needs to be pushed out to the relevant methods too.
More i18n examples.
Returns a chunk of HTML markup for a given ‘method` on the form object, wrapped in an `<li>` wrapper tag with appropriate `class` and `id` attribute hooks for CSS and JS. In many cases, the contents of the wrapper will be as simple as a `<label>` and an `<input>`:
<%= f.input :title, :as => :string, :required => true %>
<li class="string required" id="post_title_input">
<label for="post_title">Title<abbr title="Required">*</abbr></label>
<input type="text" name="post[title]" value="" id="post_title" required="required">
</li>
In other cases (like a series of checkboxes for a ‘has_many` relationship), the wrapper may include more complex markup, like a nested `<fieldset>` with a `<legend>` and an `<ol>` of checkbox/label pairs for each choice:
<%= f.input :categories, :as => :check_boxes, :collection => Category.active.ordered %>
<li class="check_boxes" id="post_categories_input">
<fieldset>
<legend>Categories</legend>
<ol>
<li>
<label><input type="checkbox" name="post[categories][1]" value="1"> Ruby</label>
</li>
<li>
<label><input type="checkbox" name="post[categories][2]" value="2"> Rails</label>
</li>
<li>
<label><input type="checkbox" name="post[categories][2]" value="2"> Awesome</label>
</li>
</ol>
</fieldset>
</li>
Sensible defaults for all options are guessed by looking at the method name, database column information, association information, validation information, etc. For example, a ‘:string` database column will map to a `:string` input, but if the method name contains ’email’, will map to an ‘:email` input instead. `belongs_to` associations will have a `:select` input, etc.
Formtastic supports many different styles of inputs, and you can/should override the default with the ‘:as` option. Internally, the symbol is used to map to a protected method responsible for the details. For example, `:as => :string` will map to `string_input`, defined in a module of the same name. Detailed documentation for each input style and it’s supported options is available on the ‘*_input` method in each module (links provided below).
Available input styles:
-
‘:boolean` (see Inputs::BooleanInput)
-
‘:check_boxes` (see Inputs::CheckBoxesInput)
-
‘:country` (see Inputs::CountryInput)
-
‘:datetime` (see Inputs::DatetimeInput)
-
‘:date` (see Inputs::DateInput)
-
‘:email` (see Inputs::EmailInput)
-
‘:file` (see Inputs::FileInput)
-
‘:hidden` (see Inputs::HiddenInput)
-
‘:number` (see Inputs::NumberInput)
-
‘:password` (see Inputs::PasswordInput)
-
‘:phone` (see Inputs::PhoneInput)
-
‘:radio` (see Inputs::RadioInput)
-
‘:search` (see Inputs::SearchInput)
-
‘:select` (see Inputs::SelectInput)
-
‘:string` (see Inputs::StringInput)
-
‘:text` (see Inputs::TextInput)
-
‘:time_zone` (see Inputs::TimeZoneInput)
-
‘:time` (see Inputs::TimeInput)
-
‘:url` (see Inputs::UrlInput)
Calling ‘:as => :string` (for example) will call `#to_html` on a new instance of `Formtastic::Inputs::StringInput`. Before this, Formtastic will try to instantiate a top-level namespace StringInput, meaning you can subclass and modify `Formtastic::Inputs::StringInput` in `app/inputs/`. This also means you can create your own new input types in `app/inputs/`.
251 252 253 254 255 256 257 |
# File 'lib/formtastic/helpers/input_helper.rb', line 251 def input(method, = {}) = .dup # Allow options to be shared without being tainted by Formtastic [:as] ||= default_input_type(method, ) klass = input_class([:as]) klass.new(self, template, @object, @object_name, method, ).to_html end |