This issue has been reported as issue #152

Closing, duplicate.

Ignore this, I'd cocked up and was using the wrong method for the form. Took me waaaaay too long to spot that.

Many apologies, Merry Christmas, and thanks for an awesome gem :)

OK, merry christmas you too. =) Closing.

I've just realize that you can do:

validates_presence_of :company

that solves the problem, I am sorry, I didn't know that.

Yes, that's the way. Closing.

Could you please provide a failing spec or a full code example with expectations?

Oh, duplication of issue: http://github.com/justinfrench/formtastic/issues/#issue/152. Closing this one.

Added clarification in the commit comments for exactly what this patch fixes.

Closing for lack of interest.

Closing.

Ok, Sorry about all the issues with the previous patch :)

Here is a patch that should cover all use cases and keep the current tests intact while adding a new one for this issue.

http://github.com/lardawge/formtastic/commit/984d7b0d08070710f5fdb101d3325451bb72d2f7

I can't think of a use case where you would need to use translation via activerecord but still use label_str_method for non-activerecord objects. I assume if you rely on translation it would be for everything. So setting label_str_method overrides activerecord if changed from default.

Thanks! Applied! :)

Build failed... related?http://runcoderun.com/justinfrench/formtastic/builds/280897a7cf939c7056a3eccb5ebb522a70efad0f/1/ruby_186
http://runcoderun.com/justinfrench/formtastic/builds/280897a7cf939c7056a3eccb5ebb522a70efad0f/1/ruby_191

Don't think so, looks like there is still a failure even with my change removed... Something changed however.

My bad, applied the patch without running specs, already fixed! :) Used with_config since the spec was changing config values.

I stand corrected :)
Note to self, run FULL spec suite before AND after any changes.

Yeah, that's why I added the with_config block... it was too easy to change a config value and break any specs that followed it.

I noticed this as well. I believe the class will respond to human_attribute_name even if the translation is not defined explicitly. In that case, it just returns a humanized version of the attribute. You may need to do something more clever like compare the human_attribute_value to a humanized string and use the label_str_method only if they match.

Justin, Now we know what broke... I will have a look...

Ok, looks like José reverted your patch on master. I'm going to revert the doc patch that went with it. Clearly we need some specs that describe the current behaviour well, then we can figure out a patch that works for everyone.

I'm going to go make an un-broken gem ;)

Changed tags to 1.x too, happy for it to be done sooner, but it's not a blocker.

Ah, this should be closed as I've pushed a new gem, will find the previous issue and re-open.

+1 I get around this for the time being by using :input_html => { :name => '.....' } but it's not ideal. Perhaps a test for this ;-)

OK, I got it. For some reason there are missing specs for name attributes. I got this one failing as well, will just trace it down now.

See:

http://github.com/grimen/formtastic/commit/0e649875eb6639de9ddbd6462a46ba4c8660a237

Note: The Rails select helper don't treat :multiple => nil as "no value", the :multiple option key must not exist in such cases. xP

Fixed the mysterious incorrect DOM name generated for select + belongs_to. Closed by a9651db.

Pulled, new gem pushed.

I've ended up changing:
@class_name.constantize.content_columns.reject to
@singular_name.classify.constantize.content_columns.reject

and it works for my purposes

OK, this is not really a bug - because this is somewhat odd scenario. You should specify the model name, I'm 90% sure this is the way Rails handles it as well. The form layout don't depend on any details in the controller, rather the model. Closing.

Hang on, I agree that the arg is intended to only be the model name, but...

1. the code should be more resilient to such misconceptions -- perhaps throw an error if there's a slash or :: namespace in the model param?

2. it's still a valid suggestion that you can choose where in the view hierarchy this should go, perhaps with a second arg?

   script/generate form thing admin/thing --partial

?

OK.

See:

http://github.com/grimen/formtastic/commit/02401ceeafdf6a5692faa9b8ec3d2bbecae3845e

Check?

This doesn't seem to do the trick:
script/generate form admin/thing --partial --haml
create app/views/admin/things
create app/views/things/_form.html.haml
No such file or directory - /Users/marc/Sites/test/app/views/things/_form.html.haml

sg form admin::thing --partial --haml
exists app/views/admin/things
create app/views/things/_form.html.haml
No such file or directory - /Users/marc/Sites/test/app/views/things/_form.html.haml

Odd, I think I need to spend more time on this one...Rails generator internals is a mess (really) - good thing Rails 3 will rock a shiny new one.

This works for me, but I had to add a optional flag (--controller CONTROLLER_PATH) to support all three major cases:

http://github.com/grimen/formtastic/commit/827c6c786acdab8864c4dffcaf58958b72e307dc

Meaning: Model might be namespaced - or might not, and that could be a mess in Ruby 1.9.

Brilliant!

script/generate form thing --partial --controller admin/things
exists app/views/admin/things
create app/views/admin/things/_form.html.erb

Appreciated :)

Fix for the form generator: Allows controller namespace to be specified, but strips out the namespace for the model. Closed by 24ec121.

pulled in, closing

Weird, the rescue don't trap that one... =S

self.model_name.constantize.content_columns.collect { |c| c.name.to_sym }.compact rescue []

...haven't tried it myself yet, but as u running 0.9.4...

I can't reproduce this in a spec (did my own non-activerecord-dummie-class without any methods/attributes). Could you maybe?

It is erroring on line 424 which is not rescued. Try testing it again with a single attribute and pass an object to semantic_form_for

class Foo
  attr_accessor :attr
end

This works:

<% semantic_form_for(:foo, :url => '/' do |f| %>
  <%= f.inputs :attr %>
<% end %>

This errors:

<% semantic_form_for(Foo.new, :url => '/' do |f| %>
  <%= f.inputs :attr %>
<% end %>

Which is expected since the symbol fails the conditional check on line formtastic.rb:423 and is rescued on line formtastic.rb:426. But when passed an object it passes the conditional check and gets the undefined method error since it is not rescued on line formtastic.rb:424.

Hope that helps.

Oh, peep the master version - this one is patched (actually more like refactored, but handles such errors with the line I dropped in the first reply) already for 0.9.5. Stay tuned.

See:

http://github.com/justinfrench/formtastic/commit/616c42a368adc578074e615c9e119b52d1359689

Closing, could not reproduce in master.

Cool man, thanks for looking at it.

The hidden values are there because Rails expects the three-part date params to all be there. :discard_month means it will render a hidden input for the month "1" instead of a select box of options. This is also exactly what Rails does with date_select.

I don't think :as => :date should be your chosen input here. It looks like you just want to pass in a year, in which case a :select with a :collection of relevant years will do. Either way, this isn't a bug, so I'm closing it. Please discuss on the google group if need be.

Awesome. It doesn't apply on master, but it should be easy for me to coerce! I can't shake the feeling that I'm missing something here.... I wonder why it was ever this complex? Grimen? José?

I got no clue, I haven't looked into that specific functionality at all - there are some contexts of the code that I'm not really know anything about. =)

Fuck it, I'll apply it and see what happens ;)

Applied, with a little coercion :)
http://github.com/justinfrench/formtastic/commit/863e3ffc6bdd19499379b7f1adfe67740b60df2b

Closing.

This patch was reverted. How do I re-open an issue? Github's busted?

See 147

See 148 I mean.

version
justinfrench-formtastic (0.2.4)

Question 1: "Why ended at 2014?"

You can adjust this using Rails core options (e.g. :end_year):

http://railsapi.com/doc/rails-v2.3.4/classes/ActionView/Helpers/DateHelper.html#M005680

Question 2: Digits instead of month names...

Passing this ball to Justin, I never seen such behavior and don't really got a qualified guess why right now. =S

Those months look really odd. Will look into it.

Questions: 1. Are you using Globalize? 2. Have you tried to remove other plugins to see if behaviour still exists? Similar problems seems to be an issue with Globalize.

1 - yes, i'm using globalize2
2 - not yet

I just added a spec locally to ensure that this bug isn't in master, and the spec passed:

it 'should use month name' do
  output_buffer.should have_tag('form li.date fieldset ol li select option', /^jan/i)
end

I'm closing this for now because it sounds like an incompatability, please feel free to re-open, or nag us on the Formtastic google group.

I did that as well ^ xD

Not using globalize but still having this issue!

I realize it happens on the built in I18n, but only when the locale is not :en.

Not for me.

Can you spec it?

Found out why already. Missing date time translations will cause this weird issue. I am using zh-TW locale.

Duplicate...closing.

Question 1: "Why ended at 2014?"

You can adjust this using Rails core options (e.g. :end_year):

http://railsapi.com/doc/rails-v2.3.4/classes/ActionView/Helpers/DateHelper.html#M005680

Question 2: Digits instead of month names...

• Passing this ball to Justin, I never seen such behavior and don't really got a qualified guess why right now. =S

Duplicate, closing....

which issue duplicated by my post?

See:

http://github.com/grimen/formtastic/commit/78ea69781a0766c39d07060516e3ac774e74cba2

Smarter detection of enum type columns (usually saved in string/varchar fields); a select input will be the default if no :as option is set but :collection option is set. Closed by 4a49e97.

See:

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

Localized (I18n) titles now also works for inputs with the :for option set (nested forms). Closed by 38d7196.

I'm 99%b certain this will fail now that I've addressed an issue with the specs which were masking the previous bug (and this bug ;)). See http://github.com/justinfrench/formtastic/commit/8fb11e177a3ecc0d0847ca8fbc83f4caf95544fd

So, we just need to find a way for this that actually works. I tried your version, and also template.content_tag, both failed. I've reverted it back to the old hand-coded HTML string for now, so this isn't super critical, it's just a refactor/clean-up for 1.0.

Weird...I didn't write any specs because I didn't know how to spec it and also I thought that would work hands down. Well the old string version is okay I guess; I was just doing the content_tag while I was on it...the I18n stuff was the important change.

Closing,,,

Are you seeing this error running specs, or running the code in your app? Very strange.

I saw it when installing Formtastic this way:

$ sudo gem install formtastic
ERROR:  Error installing formtastic:
    formtastic requires active_support (>= 2.3.0, runtime)

and also this way:

$ sudo gem install pkg/formtastic-0.9.2.gem 
ERROR:  Error installing pkg/formtastic-0.9.2.gem:
    formtastic requires active_support (>= 2.3.0, runtime)

BTW, now that I know there's a Google Groups, I asked there.

This is a bug, I messed up the gem dependency references in jeweler gemspec definition (Rakefile).

Now - incorrect:

s.add_dependency 'active_support', '>= 2.3.0'
s.add_dependency 'action_controller', '>= 2.3.0'
s.add_dependency 'action_view', '>= 2.3.0'

Correct:
s.add_dependency 'activesupport', '>= 2.3.0'
s.add_dependency 'actionpack', '>= 2.3.0'

Patch on the way. =P

Cool. Thanks. Will you generate another gem or should I install from source?

Backup-solution until there's a live one:

With jeweler:

cd /tmp
git clone git://github.com/justinfrench/formtastic.git
cd formtastic
*doing the edit in Rakefile*
rake gemspec && rake build && rake install

Thanks Jonas, I now have it installed.

@pupeno: Good to hear it worked out.

Patch...see:

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

Closing, the 093 gem should resolve it.

What Formtastic gem version you use?

I'm running justinfrench-formtastic (0.2.4)

I'm like 95% sure this works if you just update to current gem version. I saw you asked about this back in April at Stackoverflow, and at that time Formtastic didn't respect this. I patched this myself, so I'm aware of this used to be a problem.

grimen, I'm running the latest one installed by gem install today. Should I get an even more recent one? How?

BTW, on April I wasn't doing any Rails, so it must have been someone else.

The patch was included in 0.2.5+ version of the gem. I think you should upgrade either way; FOrmtastic is under heavy development and there been plenty of bug fixes since 0.2.4 - should not break anything.

Here you got the patch:

http://github.com/grimen/formtastic/commit/2b81d9af385dadf8b37dc14f387afe3d43e4958a

Closing.

grimen, can you confirm the bug is present in the current release but not in the development branch?

It's in 0.2.5+, I'm 100% sure. But I still suggest 0.9.2.

Oh, the reason I was picking an old one is because I was using justinfrench-formtastic instead of formtastic from gemcutter.

Pupeno, the gem is now on Gemcutter, so you'll need to add that as a source. If you're still having trouble, please have a chat on the google group.

I had gemcutter on my sources but I was installing justinfrench-formtastic instead of formtastic.

Thanks.

Ok, with formtastic 0.9.2 it's working fine as long as I use form_for. If I use semantic_form_for and use the form_for methods inside, I get the broken behavior (not sure if this is something you'd consider a bug or just the current behavior).

It's the expected behavior for Formtastic - but it's not interfering with form_for.

pupeno, instead of the div wrapper that Rails uses (which can cause all sorts of CSS positioning issues and limitations, we remove that wrapper and add an "error" class to the wrapper around the input, which is better because it means you can actually style the whole li block, or the label, or anything else associated with the error.

This line seems to be invalid as well:

output_buffer.should_not have_tag('form fieldset.inputs #post[author]_1_login_input')

I dont' get that one either. Justin?

José added that in, and I believe it was there primarily for an array of string values or similar. It's a good idea, but obviously the onus is on the author to make sure they only use it when the values are suited as class names, rather than the onus being on Formtastic to ensure validity.

We basically need to sanitize the strings, but I'm not in that much of a hurry :)

Without valid XHTML Nokogiri won't work, so migrating to the newer rspec matchers won't be a good idea then. I do feel that valid XHTML should be a high priority goal though; #post[author]_1_login_input is not a valid DOM ID for sure:

Should match:

[A-Za-z][-A-Za-z0-9_:.]+

See:

http://github.com/grimen/formtastic/commit/47a78e9371770264fe823244f81105f5b0ef3f2a

Replacing dependency rspec_hpricot_matchers (Hpricot) with rspec_tag_matchers (Nokogiri); specs runs faster, and rspec_hpricot_matchers was not really maintained anymore + Nokogiri is more live project. Also fixed generation of invalid DOM for radio_input/check_boxes input types. Closed by ca12563.

pulled in, closing.

Yeah, it's not in the immediate work I was doing, but there is going to be some HEAVY shifting around post 1.0 :)

Closing this for now though.

<fieldset> isn't generated either

That's why the inputs block is provided, to create those fieldset/ol wrappings. The DSL still works if you don't provided it because an LI tag is still valid outside of an OL wrapping, and fields are okay outside of fieldsets.

As for the documentation, the examples all (should) use the inputs block, so… I'm closing this.

fair enough, the code in question was a generated login form, so I was wondering why my overridden styles where not being picked up.

I don't think this is a common case for which Formtastic should provide a solution sorry. Besides, I actually find your first example with the if...elsif...end far more readible. Closing this.

Hi,

I understand that it can be more readable on the if elsif approach but it doesn't show the role on the page in the first example, it only puts the role hidden.

Even if it sticks with the if elsif approach don't you think that it should be an "input" type label just to show to the user what he is currently doing like:

<% if @user.admin? %>
<%= f.input :role %>
<% elsif @user.supervisor? %>
<% operational = Role.find_by_name('operational').id %>
<%= f.input :role_id, :as => :label, :value => operational %>
<% end %>

Notice the change on :as => :label

It's just a suggestion, I will make a fork for me anyway and I think it's a good approach because altough the user can't change the input it's good practice that the user should see the data.

Greetings

Ok, I think I better understand what you want now. You want the value to be editable by some people and not by others. For those that can't edit the data, we should display the value that would normally have been shown as the select option. Correct?

(the original poster confirmed this via a direct message)

My preferred method is to render as a :string with a disabled attribute and then use CSS to alter the appearance of the text field to look like plain text (remove the border, etc).

<%= f.input :ranking, :as => :string, :required => false, :input_html => { :disabled => true, :value => @post.ranking } %>

Closing this.

Yup, good idea.

Additions:

• :selected option should be available for: select, radio, boolean, check_boxes, time_zone (partial), country
• :selected should accept multiple values for: select (with :multiple => true), check_boxes

Any weird assumptions, or did I forgot any cases?

Yes, all correct.

Part 1, see:

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

Part 2, see:

http://github.com/grimen/formtastic/commit/4613608927103d5008c3d6de8b3f6075fb6d7a3c

Part 3, see:

http://github.com/grimen/formtastic/commit/7ebb30b2aa69c6278fb4a3ebf07dc4ba29994c15

Part 4, see:

http://github.com/grimen/formtastic/commit/4d94fb2726fded0dfe0160bc0839991eb40f8fda

I'll not do the country input type now, as it's a bit unclear how that works - 3rd party. Justin, what's ur thoughts on this?

This issue is "sort of" done, but I'll leave it up to you Justin to club that. Boink-Boink! =)

Added support for this for date/time inputs too, see:

http://github.com/grimen/formtastic/commit/2e641c2ad51e1ca0d4a9b7ab2b14bad5b961fd8a

Pulled in, will be in next patch.

doing the happy dance ;)

Awesome work!

My opinion that this is way too much of a human factor to add to README, but I would suggest adding a paragraph to the FAQ wiki page.

Thanks for the advice. I just added a quick blurb to the tutorial wiki page.

http://wiki.github.com/justinfrench/formtastic/tutorial

Cool, I was looking into the discussion and saw the config.plugins stuff...the one above do fit in the README, like so:

http://github.com/grimen/is_visitable/blob/master/README.textile

Something like that?

Closing.

There's no way that I know of to catch this. The damage is done as soon as the = is read, as far as I can tell. Closing, will gladly accept magical patches :)

I have created a patch here: http://github.com/kjeldahl/formtastic/commit/3f66d9e07b16bca5a1ca8a08bca171e4097b250a

I have implemented the original :group_by option and I didn't have the above requirement, but I agree that it should just work.

The patch looks good, but it would be nice if you could write some specs that fail without your patch and pass with your code to prevent regression later on.

kjeldahl, please add a spec to your fork so I can pull this in and release it straight away!

I will make the spec

I have just pushed the spec.

I added the self association on Post so it now belongs to a main_post and has_many sub_posts. Please have a look at the mocking and stubbing to ensure that the test is actually valid.

I have not yet added a spec the the third case mentioned in the patch. Primarily because it wasn't an issue for me, so perhaps the code should just be removed?

Looks thorough! Justin?

Great work, will pull in soon, as the patches no longer apply since I pulled in Grimen's marathon of commits. Will work it out.

Ok, something ain't right with my merge.

meantime:~/dev/formtastic (master)$ spec spec/inputs/select_input_spec.rb
............................................F........................................................................................................

1)
Spec::Mocks::MockExpectationError in 'select input for a belongs_to association with :group_by => :author should call author.posts'
/Library/Ruby/Gems/1.8/gems/rspec-1.2.9/lib/spec/mocks/error_generator.rb:64:in __raise': Mock "user" received unexpected message :main_posts with (no args) /Library/Ruby/Gems/1.8/gems/actionpack-2.3.4/lib/action_view/helpers/form_options_helper.rb:388:inoption_groups_from_collection_for_select' (eval):1:in option_groups_from_collection_for_select' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.4/lib/action_view/helpers/form_options_helper.rb:388:inoption_groups_from_collection_for_select' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.4/lib/action_view/helpers/form_options_helper.rb:385:in each' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.4/lib/action_view/helpers/form_options_helper.rb:385:ininject' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.4/lib/action_view/helpers/form_options_helper.rb:385:in option_groups_from_collection_for_select' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.4/lib/action_view/helpers/form_options_helper.rb:552:into_grouped_collection_select_tag' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.4/lib/action_view/helpers/form_options_helper.rb:214:in grouped_collection_select' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.4/lib/action_view/helpers/form_options_helper.rb:592:ingrouped_collection_select' ./spec/inputs/select_input_spec.rb:112: /Library/Ruby/Gems/1.8/gems/actionpack-2.3.4/lib/action_view/helpers/form_helper.rb:490:in fields_for' /Library/Ruby/Gems/1.8/gems/actionpack-2.3.4/lib/action_view/helpers/form_helper.rb:282:inform_for' ./spec/inputs/select_input_spec.rb:111:

Spec around 111:

describe "for a belongs_to association with :group_by => :author" do
  it "should call author.posts" do
    [@freds_post].each { |post| post.stub!(:to_label).and_return("Post - #{post.id}") }
    @fred.should_receive(:posts)
    semantic_form_for(@new_post) do |builder|
      concat(builder.input(:main_post, :as => :select, :group_by => :author ) )
    end
  end
end

Any ideas?

Also, why did you put these in spec_helper?

@new_post.should_receive(:publish_at=).any_number_of_times
@new_post.should_receive(:title=).any_number_of_times

I think it was me adding those last 2 lines in the spec_helper. My reason was: I don't like mocking/stubbing. Sometimes totally overkill actually. Remove 'em if you get the specs to run. ;)

...but if I remember correctly, you don't want to xD

Ok, found the issue(s), have wrestled with git and pulled this bad boy in!
http://github.com/justinfrench/formtastic/commit/9c1daba14daea0d56d309d64322b87d570af832c
http://github.com/justinfrench/formtastic/commit/7a2ef48dfffc69875debd094522ee967ad2640d4

Closing, but feel free to review!

Damn that comment just ate my code - all you need to know is that the option values are usually integers instead of the desired string

Sorry, I don't understand your question. Could you clearify what you expect? Also, I would suggest putting the code in a gist or pastie.

This should do it:

http://pastie.textmate.org/705881

Sorry, I can't reproduce this. Can't get the spec to fail even with loading a raw YAML file. Either we need a failing spec or a physical proof (see http://github.com/grimen/test_app) - or it'll be closed.

Data:

en:
  titles:
    - Mr
    - Ms
    - Dr

Spec (one of them, all different flavors passed)

describe "from I18n lookup" do
      before do
        translations = File.open(File.join(File.dirname(__FILE__), *%w[.. data en.yml])) { |file| YAML.load(file) }
        ::I18n.backend.store_translations :en, ::HashWithIndifferentAccess.new(translations)[:en]
        
        semantic_form_for(@new_post) do |builder|
          concat(builder.input(:title, :as => :select, :collection => ::I18n.t(:titles)))
        end
      end
      
      it "should load option values correctly" do
        output_buffer.should have_tag('form li select option', 'Mr')
        output_buffer.should have_tag('form li select option', 'Ms')
        output_buffer.should have_tag('form li select option', 'Dr')
      end
    end

Proof:

http://github.com/grimen/formtastic/tree/issue_123_spec

I spoke with our team about this and it turns out the problem is related to our use of Globalize. I tested out a fresh app and did not have this issue but as soon as I installed Globalize I got those weird integers.

As a temporary fix I just do something like this:

:collection => I18n.translate('titles').map(&:to_s)

Which gives the desired result.

OK, great. I had major issues with Globalize and GLobalize 2, so I dropped it for good. Doin fine without it - there are thinner alternatives that work very well for me: http://github.com/janne/model_translations

Closing this.

Of course, I could do this (not a big change) but will probably wait for your refactoring.

My refactoring got shelved again, go for it :)

See:

http://github.com/grimen/formtastic/commit/1444aa2edca5c54222b0a8d1b7f0f28e1e91f31d

Refactored I18n stuff to Formtastic::I18n with specs. Cleaner. Closed by 382c552.

• 1 for this, as it's something I end up doing anyway.

I got something that "should" work here, but RSpec says it's not. Please feel free to review what's up with that. 98-100% complete that is.

http://github.com/grimen/formtastic/commit/59d844d5aa708a874feb8c49071c5e5b89bff1ad

To clearify: There are 3 failing specs that should not fail, but they do because form.object/@object is set to nil for some reason... =P

Got it right, see:

http://github.com/grimen/formtastic/commit/8eb0abb4acac3fec5f1d02ebd66494cb92e3cc08

Got around the issue with date/time not being set to Time.now if no value is set. All specs now pass. Closed by cf3a860.

Go for it!

Mailed the dude behind, trying to get him to claim the project and get it on gemcutter. Might take some time, but no hurry really.

Update: I forked that project as "rspec_tag_matchers" and it now lives on Gemcutter after some modifications. On Ruby 1.8.7 specs run 4 seconds faster. B) For some reason specs run slower on Ruby 1.9 (wierd), but "rspec_tag_matchers" is 1-2 seconds faster.

Note: Hey, in 4 seconds you can run and push the coffee machine button (I noticed)! ;)

Why closed?

This works:

<%= f.input :object_id, :as => :hidden, :value => @object.id %>

...but I can agree that this is a bit inconsistent. What do you think Justin?

See:

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

I think this should be possible to set the value using html_options. My argument is that it's confusing that only hidden_input lacks the html_options hash just because it's not a visible input.

So you've made the API the same as, say, string input?

Uhm, not sure what you mean, but see the spec. The only input_html-option that works is :value - so that people don't get stuck like jduarte did above. This might need a bit more reflection maybe, but I just pushed this so we got something physical (digital). =)

jduarte said:

It's a little bit off-topic but since we're talking of hidden inputs.
For me it doesn't make sense an hidden input being wrapped in a li tag by default.
I think it can mess up uneccessarely with the CSS.
What do you think?

Yes, maybe hidden fields should be placed in a hidden div in the form header just like Rails does this. Should be straight-forward to do with the content_for helper. Makes sense to me.

Hidden fields cannot be rendered without the LI wrapper because it's invalid to have child elements of an OL or UL that are not an LI, which is why we render them within an LI, and why the default stylesheets supplied with formtastic hide li.hidden inputs. Closing.

But did you reflect on my last suggestion? Se how the security token gets attached to a Rails form. My suggestion would be to stack them all like that.

Ah, I missed the content_for bit of your message. Absolutely, feel free to have a play!

Actually, it should be mentioned in the README too?

Agreed.

See:

http://github.com/grimen/formtastic/commit/101c8138c096c41aea531c43fa8de29c37a67602

Added documentation for the form generator in README, and showing some instructions on plugin and gem installation. Closed by fef3288.

I don't agree. Just because an field is required, that doesn't mean that the form should make a default choice for you (typically the first option). By having a blank default, you can ensure that the user actually makes a choice.

Ultimately, this comes down to a mixture of personal preference and a case-by-case basis. You suggestion is not always appropriate, neither is the current implementation, which is why we added a global preference and an option into the DSL on a field-by-field basis.

I'm not particularly excited about adding a further configuration, closing for now.

Oh, hadn't thought of that leaving the blank choice is what I want too, sorry for the noise.

I don't really get this one, seems more like a misunderstanding of the API to me. Got a hint?

This was a typo/misunderstanding-issue. No bug, closing.

I noticed this as well, but not sure how many use-cases there are except for integer ranges - and that is very easy to implement with (a..b).to_a or [*a..b], so I never thought about it further myself. The question we need to ask now is: How many use cases we got for ranges except for range of Integers? If there are a few, and they all can be implemented in a way that makes sense, you get my vote on this one.

Doesn't seem like a big deal to support this, I'll gladly pull this in when there's some specs!

See:

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

Added support explicit values of type Range for the :collection option of the select input, e.g. form.input :rating, :as => :select, :collection => 1..5. Added specs for both ranges, and explicit array values which was lacking. Closed by 440bd2d.

Closing again.

Would've loved some specs for this before applying, but I'm in a good mood and really want to clean up the forkqueue a bit, so you might get lucky ;)

Hmmm, in your patch, this seems to be only applied if you have :as => :string, because the code you wrote is skipped for :as => :numeric, which would be the default type for a decimal column. Having a play...

I tried to write some specs for this, and I encountered two problems. The code supplied in the patch was bypassed for numeric inputs (which is the default for a decimal field), so in attempting to correct this, I realised we had some pretty good reason not to apply sizes and limits for numeric inputs, as discussed in issue #19.

I'm not smart enough to know I've covered off all the considerations necessary for all databases and number-like column types, so my proposed solution right now is that you use :as => :numeric, which will not apply a size or maxlength.

Closing this for now, please feel free to re-open if you wish to discuss, or have a solid patch with coverage.

Justin, if I spec and implement this - will it be of interest yet?

I really don't want to open the "custom inputs" issue right now, in any shape or form :)

OK, I maybe do this in a experimental-branch so we can play with it.

After some code experiments: Closing this in favor for http://github.com/justinfrench/formtastic/issues/#issue/46

This one (:with) adds too much complexity, and can without complexity be solved using the "issue-46-way".

fixed in 23978ad

Hmm...this works for me:

= form.input :animals, :as => :select, :collection => [["Duck", 1], ["Horse", 2]]

=>

http://pastie.org/691756

(Grrrr....I hate GitHub the markup not accepting HTML tags in PRE)

Cool, not a bug then!

Instead of pre, markdown needs four spaces at the beginning of a code line to turn it into a code block, FYI

Oh thanks for the info, that bugged me for a long time.

fixed in a8e2f2e

Stack trace? The one provided is not enough. (Note: I've used ::I18n instead of I18n in the most common places so that this should never ever happen, but older I18n code don't. Should not be an issue with Ruby 1.8.x though...)

I believe we can make this never happen quite easily with just using ::I18n everywhere, but I'm not sure how to spec this - even in Ruby 1.9 where this could happen sometimes because Ruby 1.9 sometimes do this ind of namespace assumptions. In other words: I guess we have to skip specs for this one. Patch in progress... =)

See:

http://github.com/grimen/formtastic/commit/9f20d0e621651cc86e7fade1ec26cced0bf1b478

Adding "::" to I18n and Formtastic constants to avoid namespace issues (especially a issue in Ruby 1.9). Closed by e3c200a.

Closing again.

You can turn it off on a global level by omitting it from the inline_order configuration, at a model level by not adding error messages, or if none of those appeal, I'd recommend to simply hide the errors at a presentational level with CSS, eg:

form.formtastic #article_title_input ul.errors { display:none; }

I'm closing this issue for now, let me know if you believe none of these options are appropriate.

Consider the case of a login form say using Authlogic. I don't want to display the actual error message for the form fields username or password because this opens up a security floor. Instead I want to display a generic error message. e.g. "username or password incorrect".

In this case I don't want to turn the error messages off on a global level. This will affect all other forms in the application where I need the errors displayed.

On a model level I would have to override the "errors" method and remove the messages on username and password. This is also not ideal. And I think this is more of a view issue anyway.

Lastly as you mentioned, I could simply hide the error on a presentational level as in your example above. However this will still show the error messages in the source, again opening up the security hole.

What do you think?

+1 dwilkie

Ok, that's a pretty special case, but I agree with you I guess. Thinking about it!

...an the I18n-way should work the same way of course:

- inputs :some_fieldset_title do
  = input :title

It looks like this should work by the look of the code. Should only be triggered if block is given. Did I miss something though?

I'm not following. What's the relationship between...

inputs :title => "fieldset legend text goes here"

and...

input :title

The latter renders an input for the title attribute on the model, the former adds a legend to the fieldset.

I think you meant to type:

input :name

in your example, yes?

If so, I'm following ;)

Ouch, yes - I blame the tiny GitHub comment box. =) Removed :title to not cause confusion, fail. Trying again:

- inputs :title => "My little fieldset" do
  = input :yahoo

...with an equivalent way:

- inputs "My little fieldset" do
  = input :yahoo

Tag this one with 1.x, or what's the current consensus?

Yeah, I'm okay with this, sure. 1.0'd it.

Cool, on my TODO.

See:

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

DRYer fieldset legends; check if first inputs block argument is a valid legend - the options (:name/:title) way works still, and got higher priority. Closed by 3cad250.