formtastic/formtastic

A Rails form builder plugin with semantically rich and accessible markup.

formtastic's Issues

Allow string fields to localize datetimes

As discussed in the mailing list: http://groups.google.com/group/formtastic/browse_thread/thread/3fbf2dc5f8b32ed3

:include_blank => false / :prompt

I have old forms created with version = "0.1.7" after upgrade to "0.1.9"
My selects are showing extra blank option even after :include_blank => false

Secondly I think; if I have :prompt mentioned it should not show a blank option and should retain the :prompt even in edit form along with the selected value (as it works with :include_blank => 'My Prompt')

Example :
On create
Author
Select Author Justin French Jane Doe

and while editing

Author
Select Author Justin French Jane Doe

better buttons (not pretty buttons)

I think this is really needed for 1.0. It stucks me on daily basis now. It feels like a fundamental feature, just a simple solution would be a relief right now.

Reference: http://groups.google.com.au/group/formtastic/browse_thread/thread/9bb5d808d2a9adbf

Polymorphic associations problems

In certain situations with polymorphic associations @semantic_form_for@ don't generate proper @inputs@/@semantic_fields_for@ (outputs "0" wrapped in fieldset-tag), and for other not any form at all, while this still works for Rails core helpers (@form_for@ and @fields_for@).

I haven't found the source of all this evil yet, and simply got no simple failing spec - just a live project I'm working on. I switched to @form_for@ for these cases but will look into it of curiosity as soon as I'm done with some other stuff.

need a logo!

need a home page (formtastic.github.com)

need to merge in grimen's generators

Rdoc doesn't build from the Gem

Building Rdoc from source still works however.

method_required? should consider :if conditional on validates_presence_of

See 615384e, have asked for some spec coverage.

field_error_proc override breaks standard form_for error handling

For most forms I've been using formtastic, however a few forms I don't need all the features so I'm sticking to good old form_for(@object). I've noticed that when the Formtastic gem is enabled (latest version 0.2.1), form_for no longer wraps input elements in a fieldWithErrors tag if validation has failed. Commenting out the config.gem entry and everything is back to normal.

Optimizations: String handling

I noticed two trivial and failsafe ways of optimizing Formtastic, and there are plenty of places in the current code where this applies right now:

• Concat strings with << (append) instead of +/+= (concat)...or even better (but sometimes less readable) using interpolations. Reasons: Signficiant speed improvements, and no new unnessacy String instances.
• Use immutable Strings, i.e. Symbol (to_sym) whenever possible (especially for: send, I18.t, etc.)

Formtastic doing a lot of String-manipulation so... Just putting this as a note on the wall - haven't done any benchmarks on Formtastic yet but might do soon for the fun of it. 8) 1.0?

Motivation background:
http://blog.purepistos.net/index.php/2008/07/14/benchmarking-ruby-string-interpolation-concatenation-and-appending/

date ranges can't be set for date/time selects

Before creating the input we have to check if start_date/end_date or start_time/end_time were given and parse start_day/start_month/start_year and so on from it.

Failing example:
f.input :my_date, :as => :date, :start_date => Date.today, :end_date => Date.today + 365

Child index vs. inputs block

In the doc, the only way to interpolate through has_many with child index numbering is to use <generator>.inputs :for => <scope>. However, it doesn't accept blocks, eg. only the most basic solution is supported.

I'd like to give block to .inputs to hand-craft the form, but I'd like to use child index numbering as well. For the first half, I have to use <generator>.semantic_fields_for, but it doesn't set params[:parent] implicitly. However, this setting is a requirement for calling parent_child_index (obviously).

Maybe params[:parent] could be transferred in formbuilder's options somehow to the child scope.

Bug: Inline-errors gets rendered for :hidden inputs

Inline-errors gets rendered for :hidden inputs. I believe this is incorrect behavior, as hidden fields are hidden no matter if one use CSS or not, therefore the same should apply to inline-errors on such inputs.

Wrapper around country select

A new input :as => :country should be added, which means we either require one of the country select plugins, or simply support any plugin that defines country_select as a form helper method.

Using :label => false results in error

Attempting to use :label => false results in the following error:

You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.+

need readily accessible rdocs generated with each new gem

documentation / README updated needed for label/hint localization

see fbf01b9

New released gem 0.2.4 not generated by github

Hello,
the new bump for gem 0.2.4 is still not released in github, probably github issues =). Could you please give a try bumping the gem again (ie 0.2.5)?
Thanks, Carlos.

Allow :label_method to be a proc, so you can keep rendering logic out of your model

See http://github.com/xaviershay/formtastic/commit/29b7b62f59948f63b97cfba4c9f69d47acce7488

When I supply :author formtastic tries to be smart and get the I18n label under :author_id

Make :include_blank => true default on :as => :select

the ability to provide :prefix and :suffix strings

Here's some real-world examples I've found recently:

[input] mt

[input] square meters

AU$ [input] excl. GST

These can all be "solved" with some help/hint text below the input or a verbose label, but I think we should try to figure out a better solution.

specs fail a lot with ruby 1.9.1

There are serveral problems with ruby 1.9.1
First it will not run any specs at all because instance vars are not allowed as block arguments

semantic_form_for(@new_post) do |@builder|
                                 ^

Im not sure if this is a typo or it makes any sense with ruby 1.8.6 because these appear only 2 times.

After fixing this nearly all specs fail because of missing methods errors.
The missing methods are all defined at line 43-51 in formtastic_spec.rb so I assume there is a scoping problem which I was unable to get around.

When passing in a collection of strings of the label_method should still be able to be applied.

For example when doing:

<%= form.input :gender, :as => :select, :collection => Profile::GENDERS, :label_method => :humanize %>

This won't work currently as in find_collection_for_column there's the optimisation:

  # Return if we have an Array of strings, fixnums or arrays
  return collection if collection.instance_of?(Array) &&
                       [Array, Fixnum, String, Symbol].include?(collection.first.class)

If you remove that it works as expected.

It might make more sense to check the existance of the label_method and the value_method and only collect if one is present.

Allow shortcut syntax for commit_button

We could allow both:

f.commit_button "Go go go!", :button_html => {:class => 'narrowForm'}

And

f.commit_button :button_html => {:class => 'narrowForm'}

still deprecated methods around in edge

formtastic.rb L#93, change to @object.errors[method.to_sym]
formtastic.rb L#382, change to @object.errors[method.to_sym]

Support for custom form element styles

In order to use pretty iPhone-style checkbox toggles (Look: http://awardwinningfjords.com/ ), instead of using a plain old boolean_input (which in this case makes an erroneous assumption about how I'd like my label marked up) I had to add this custom input type:

def iphone_toggle_input(method, options)
  html_options = options.delete(:input_html) || {}
  html_options = default_string_options(method).merge(html_options) if STRING_MAPPINGS.include?(type)
  self.label(method, options.slice(:label, :required)) +
  self.send("check_box", method, html_options)
end

Certainly, that wasn't a big whoop (once I've ironed out the CSS-kinks), but it'd be nice to be able to just "force" the regular "input_simple" style of label markup rather than the one boolean_input now assumes.

formtastic paperclip attribute detection generates wrong html

Html generated with autodetection:

<li id="model_field_input" class="string required">
     <label for=model_field">Field<abbr title="required">*</abbr></label>
     <input type="text" value="/field/original/missing.png" size="50" name="model[field]" id="model_field"/>
</li>

Html generated whenn forced to :file (:as => :file)

Field*

Singularize / Pluralize problem in formtastic breaking on status/statuses.

As per a request by Justin in this thread: http://groups.google.com.au/group/formtastic/t/cfa36ee67d8345b I am creating this issue. This is in rails 2.3.2.

The problem appears to be formtastic somehow coming up with job_statu_id insteda of job_status_id when building.

First up the stacktrace:

ActionView::TemplateError: undefined method `job_statu_id' for #<Job:
0xb6718e6c>
On line #2 of app/views/jobs/_form.html.erb

    1: <% semantic_form_for @job do |form| %>
    2:   <%= form.inputs %>
    3:   <%= render :partial => "shared/formsubmitbutton" %>
    4: <% end %>

    vendor/plugins/formtastic/rails//lib/formtastic.rb:558:in

select_input' vendor/plugins/formtastic/rails//lib/formtastic.rb:884:in send'
vendor/plugins/formtastic/rails//lib/formtastic.rb:884:in
inline_input_for' vendor/plugins/formtastic/rails//lib/formtastic.rb:99:in send'
vendor/plugins/formtastic/rails//lib/formtastic.rb:99:in
input' vendor/plugins/formtastic/rails//lib/formtastic.rb:98:inmap'
vendor/plugins/formtastic/rails//lib/formtastic.rb:98:in
input' vendor/plugins/formtastic/rails//lib/formtastic.rb:247:in inputs'
vendor/plugins/formtastic/rails//lib/formtastic.rb:247:in
map' vendor/plugins/formtastic/rails//lib/formtastic.rb:247:in inputs'
app/views/jobs/_form.html.erb:2
vendor/plugins/formtastic/rails//lib/formtastic.rb:1225:in
semantic_form_for' app/views/jobs/_form.html.erb:1 app/views/jobs/new.html.erb:3 app/controllers/jobs_controller.rb:29:innew'
/test/functional/jobs_controller_test.rb:11:in
test_should_get_new' /usr/lib/ruby/1.8/test/unit/testsuite.rb:34:inrun'
/usr/lib/ruby/1.8/test/unit/testsuite.rb:33:in each' /usr/lib/ruby/1.8/test/unit/testsuite.rb:33:inrun'
/usr/lib/ruby/1.8/test/unit/testsuite.rb:34:in run' /usr/lib/ruby/1.8/test/unit/testsuite.rb:33:ineach'
/usr/lib/ruby/1.8/test/unit/testsuite.rb:33:in run' /usr/lib/ruby/1.8/test/unit/ui/testrunnermediator.rb:46:in old_run_suite'
/opt/rubymine/rb/testing/patch/test/unit/ui/
testrunnermediator.rb:36:in run_suite' /opt/rubymine/rb/testing/patch/test/unit/ui/teamcity/ testrunner.rb:69:instart_mediator'
/opt/rubymine/rb/testing/patch/test/unit/ui/teamcity/
testrunner.rb:57:in start' /usr/lib/ruby/1.8/test/unit/ui/testrunnerutilities.rb:29:in run'
/usr/lib/ruby/1.8/test/unit/autorunner.rb:216:in run' /usr/lib/ruby/1.8/test/unit/autorunner.rb:12:inrun'
/usr/lib/ruby/1.8/test/unit.rb:278
rake (0.8.4) lib/rake/rake_test_loader.rb:5

Next up we have the schema for the two tables:

create_table "job_statuses", :force => true do |t|
  t.integer "lock_version", :default => 0
  t.string "name", :limit => 50, :null => false

  t.timestamps
end


create_table "jobs", :force => true do |t|
  t.integer "lock_version", :default => 0
  t.references :customer, :null => false
  t.references :employee, :null => false
  t.datetime "job_date", :null => false
  t.text "description", :null => false
  t.references :job_status, :null => false
  t.decimal "estimated_time", :precision => 10, :scale => 2, :default => 0.00, :null => false

  t.timestamps
end

Associations:
in the Job model: belongs_to :job_status
in the JobStatus model: has_many :jobs

The view code:
in views/jobs/edit.html.erb:
<%= render :partial => "form" %>

in views/jobs/_form.html.erb

<% semantic_form_for @job do |form| %>
<%= form.inputs %>
<%= render :partial => "shared/formsubmitbutton" %>
<% end %>

wiki needs an FAQ

to address some of the common questions we've seen leading up to 1.0

input vs inputs arguments

When using f.input :foo, :as => :text I get what I'd expect, a text area.
However when using f.inputs :foo, :bar, :as => :text, I'd expect:

(either)

A) A text area
B) An error to say it won't cast both :foo and :bar as a text area (Why though?)

SemanticFormHelper.builder config is not documented in README

OrderedHash as collection not recognized as Hash

For hard coded options for select fields I like to go with hashes since they map very nicely to the select option concept (key -> values). But since the Ruby 1.8 hash is not ordered I always use OrderedHash instead (sudo gem install orderedhash).

Formtastic didn't recognize it as a Hash at line 1075 of formtastic.rb:
collection = collection.to_a if collection.instance_of?(Hash)

I did a simple local hack and changed instance_of? to is_a?:
collection = collection.to_a if collection.is_a?(Hash)

So now the OrderedHash'es are working just fine as hashes. I didn't run any test suites against it or anything. If you agree it's a good idea I hope to see it in master.

Showing base errors

All errors for attributes are shown near fields, but base errors aren't shown at all?!

no documentation to indicate that :collection can take an Array of Strings (not just an Array of AR objects)

SemanticFormHelper.builder (configurable) should be used every time we would call SemanticFormBuilder

semantic_form_for is one example I just spotted in the code

Do not include blank on select when habtm association

Localized fieldset labels

...as mentioned in mailing-list:

Localized fieldset labels, and alias :title for :name - incl. specs:

http://github.com/grimen/formtastic/commit/effb5af778a1814dba1896e5a77f0c9981a26882

Reason for this is that localization of form fieldset titles belong to the same domain as form labels/hints I believe, and should be treatened the same way - feels very natural. Next natural step would be localized button labels too, but I had some design issues with that as the current implementation of form buttons/actions in Formtastic is not very scalable (as discussed in the mailing-list, i.e. commit/cancel etc.) - therefore I choose not to touch that until we got a solution on "the button issue".

Documentation: I18n fieldset legends/titles

(title says it all)

:radio with multiple value options? (Non-association)

I have an attr_accessor on my model that should contain one of three values. How do I code this? Doing three :as => :radio elements just creates three yes/no fields, which is not what I want.

Maybe this is a feature request, maybe I'm just too tired to find the right docs.

*_input methods need to be added to rdoc for documentation

they're private methods right now, so they need to be forced into the documentation I guess

Add :as => :hidden

Just for compatibility's sake as discussed in the mailing list.

pretty buttons

Support start_date/end_date and start_time/end_time in datetime fields

Fields named :password should default to a password input, even with non-model objects

When using a "modeless" form (without AR) a password field needs to be passed an :as => :password argument.

Unable to override :builder paramters

If I derive a new builder from SemanticFormBuilder, I can set Formtastic::SemanticFormHelper::builder to make my new class the deafult used by SematincFormHelper::sematic_form_for, SemanticFormHelper::semantic_fields_for, etc. However SemanticFormBuilder::semantic_fields_for hardcodes :builder as Formtastic::SemanticFormBuilder, and adds it to the options with merge, which prevents overriding it when called. It would be better if the class used for :builder was settable, or reverse_merge was used so that if it is passed in the options it gets used as specified

Use arrays instead of hashes in collection_boolean_attributes

Hash does not preserve the order, so "No" can appear first than "Yes". This is the default line:

  { options.delete(:true) => true, options.delete(:false) => false }

Just change to:

  [ [ options.delete(:true), true], [ options.delete(:false), false ] ]

save_or_create_button_text is changing the I18n translation in production

Hello guys,

When using formtastic in development, commit button text is being created ok, ie 'Create Product' or 'Save Product'... however, while testing it in production mode, I'm having an weird issue: commit labels are updating the translation, resulting in 'Save Product Product Product'... as many times I open the form for editing.

As translations aren't reloaded in production, changing the following code:

  I18n.t(prefix.downcase, :default => prefix, :scope => [:formtastic]) << ' ' << object_name

to this:

  button_text = I18n.t(prefix.downcase, :default => prefix, :scope => [:formtastic]).dup
  button_text << ' ' << object_name

worked nicely here.
Thanks, Carlos.

default_string_options limits integer input on MySQL to byte size (4)

:maxlength and :size is set to the byte size as stored in the DB, i.e. MySQL = 4. Suggest using html_options rather than setting any defaults, even for strings.

Work around is to pass in :maxlength and :size in html_options or use the code at this commit:
http://github.com/robertwahler/formtastic/commit/435f52ee1b5d47f67a222a7e2c459d3f322482b7

Thanks for the great plugin!
-robert