# Sensible option hashes in ActionView::Helpers::FormOptionsHelper **URL:** \ **Category:** rubyonrails-core\ **Created:** [November 20, 2007, 12:04pm UTC](https://discuss.rubyonrails.org/t/sensible-option-hashes-in-actionview-formoptionshelper/20651 "2007-11-20T12:04:20Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![August\_Lilleaas](https://avatars.discourse-cdn.com/v4/letter/a/7bcc69/32.png) [@August\_Lilleaas](https://discuss.rubyonrails.org/u/August_Lilleaas)\ **Post date:** [November 20, 2007, 12:04pm UTC](https://discuss.rubyonrails.org/t/sensible-option-hashes-in-actionview-formoptionshelper/20651/1 "2007-11-20T12:04:20Z")
First post in here, and first time I'm "contributing" to rails, so please don't slaughter me. The dual options hash in ActionView::Helpers::FormOptionsHelper is bugging me. It has one option hash for options on the method itself, and another option hash for html options, passed directly to the HTML tag. f.select :category\_id, the\_options, {:include\_blank =\> true}, {:class =\> "hello"} This is bad for two reasons. First of all, it's very un-common (and not very pretty, either). If you don't have any method-options, you'll have a pretty silly empty hash as the 3rd argument. Second of all, it nerfs the usage of with\_options on that method. I'd suggest something like this: f.select :category\_id, the\_options, :include\_blank =\> true, :html =\> {:class =\> "hai"} Just like e.g. form\_for is doing things. To ensure backwards compability, one could do something like this: def select(object, method, choices, \*args)   if args.size == 2     options = args.first     html\_options = args.last   else     options = args.first     html\_options = options.delete(:html)   end   InstanceTag.new(object, method, self, nil, options.delete(:object)).to\_select\_tag(choices, options, html\_options) end Sounds sensible? Should I make a patch and submit a ticket? ---
**Author:** ![bitsweat](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/bitsweat/32/591_2.png) [@bitsweat](https://discuss.rubyonrails.org/u/bitsweat)\ **Post date:** [November 20, 2007, 11:25pm UTC](https://discuss.rubyonrails.org/t/sensible-option-hashes-in-actionview-formoptionshelper/20651/2 "2007-11-20T23:25:07Z")
Yes it does. I agree with the two concerns you raise and have been similarly annoyed by this clunky aspect of the API. Please pursue a patch. Best, jeremy ---
**Author:** ![August\_Lilleaas](https://avatars.discourse-cdn.com/v4/letter/a/7bcc69/32.png) [@August\_Lilleaas](https://discuss.rubyonrails.org/u/August_Lilleaas)\ **Post date:** [November 21, 2007, 11:26am UTC](https://discuss.rubyonrails.org/t/sensible-option-hashes-in-actionview-formoptionshelper/20651/3 "2007-11-21T11:26:16Z")
Thanks, patch created. \*insert rant about this being my first patch to rails, and the code might not be completely ideomatic to Rails coding style\* Here it is: [http://dev.rubyonrails.org/ticket/10233](http://dev.rubyonrails.org/ticket/10233) ---
**Author:** ![Frederick\_Cheung](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/frederick_cheung/32/3901_2.png) [@Frederick\_Cheung](https://discuss.rubyonrails.org/u/Frederick_Cheung)\ **Post date:** [December 8, 2007, 5:36pm UTC](https://discuss.rubyonrails.org/t/sensible-option-hashes-in-actionview-formoptionshelper/20651/4 "2007-12-08T17:36:00Z")
Is anyone pursuing this? In addition to the helps in the match, it would be great if this was uniform across helpers (eg link\_to, link\_to\_remote, button\_to etc...) Fred ---
**Author:** ![August\_Lilleaas](https://avatars.discourse-cdn.com/v4/letter/a/7bcc69/32.png) [@August\_Lilleaas](https://discuss.rubyonrails.org/u/August_Lilleaas)\ **Post date:** [December 8, 2007, 9:29pm UTC](https://discuss.rubyonrails.org/t/sensible-option-hashes-in-actionview-formoptionshelper/20651/5 "2007-12-08T21:29:26Z")
I think that's a good idea as well, and I've actually had that very idea myself. Not sure how link\_to could be done with one option hash and still make sense. Perhaps something like what form\_for does. link\_to "Edit", :class =\> "important", :url =\> edit\_post\_url(@post) What do you think? ---
**Author:** ![Frederick\_Cheung](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/frederick_cheung/32/3901_2.png) [@Frederick\_Cheung](https://discuss.rubyonrails.org/u/Frederick_Cheung)\ **Post date:** [December 9, 2007, 11:59am UTC](https://discuss.rubyonrails.org/t/sensible-option-hashes-in-actionview-formoptionshelper/20651/6 "2007-12-09T11:59:18Z")
> I think that's a good idea as well, and I've actually had that very idea myself. Not sure how link\_to could be done with one option hash and still make sense. Perhaps something like what form\_for does. > > link\_to "Edit", :class =\> "important", :url =\> edit\_post\_url(@post) > > What do you think? Well link\_to\_remote is currently link\_to\_remote( 'Click me', {:url =\> {...}, :update =\> {'somediv'}}, {:class =\> 'foo'}) That would be nicer with a single hash link\_to 'Click me', :url =\> {...}, :html =\> {...} works, but is a little more verbose for the most common case link\_to 'blah', edit\_post\_url(@post) etc... You could conceivably rig it so that link\_to 'Edit', some\_string, some\_options is interpreted as link\_to 'Edit', :url =\> some\_string, :html =\> some\_options but link\_to 'Edit', some\_hash expects some\_hash to contain :html and :url keys (and if there is no :url key then you can assume it's old-skool. Fred