disabled attribute and lambdas for option tags

Here's an improved patch with added documentation.

Up to date patch with support added to select and collection_select helpers.

Not sure if I like the hash with disabled values, but I don't have a better suggestion either. Let's park this till post 2.2 and think a bit more about the API after that.

Thanks Michael.

Yeah, I'm not entirely happy with the API either but not sure what the alternative would be without drastic changes. In the mean time, I'll create a plugin and run it through it's paces.

I too have been wanting the ability to pass in disabled as an parameter for options_for_select. However, I needed more control than the disabled = {} offered, since I have helper methods that generate the label/value pairs for options_for_select. I needed the ability to have my helper method determine which options would be disabled, so that I wouldn't have to manually go in and specify various values as disabled (which could change and end up giving me more work to do).

So... I modified the patch that was posted and tested it out, and it seems to work great for what I needed.. I thought I'd post it back in case anyone else finds it useful.

Thank you.

Glad you found it useful. I've also turned the patch into a plugin:

http://github.com/tekin/option_t...

The test coverage is patchy but it's working for my needs until something can get worked into core.

How about if instead of passing :disable => [1,2,3] you passed a proc which would return whether an item was disabled or not (so a bit closer in spirit to what options_from_collection_for_select does for id/value)

it might look a little like

f.select :foo_id, :foos, :disabled => lambda {|foo| some_condition(foo)}

Might be over the top but feels less cumbersome than having to explicitly write out those ids that are generated

Well, I realized something still wasn't right with the behavior, and it got me to examine the original code for option_text_and_value. It originally had this respond_to?(:first) and respont_to?(:last) --- which I don't quite understand what the relevance of that was, as that seems to return true in most all cases.

Anyway, I found that I was getting an error when passing in option, values without a disabled attribute, and it was because the option_text_and_value's passed in option param was a number 5.. Which I still don't get why that was happening. Anyway, I changed things and tested it all out, and it works great (for me atleast).. Like I said, this is ideal because you don't have to manually manage the disabled in the options_for_select, but rather you can have the disabled options be part of the array passed into it.

Here is the improved code:

@Frederick - That's not a bad idea! Will work something up and make it work for :selected too.

@Patrick - the :first/:last bit is necessary to support different types of container when calling options_for_select. see the rdoc

It looks very nice!! But maybe instead of having two parameters (selected and disabled), we could pass a hash.

Rails 2.2 (or it's 2.3?) changed quite some ActionView helpers to work with hashes instead of multiple arguments because the first is much more readable.

And another tip is to refactor this little piece of code into a private method:

  if selected.is_a?(Proc)
    selected_values = collection.map do |element|
      element.send(value_method) if selected.call(element) 
    end.compact
  else
    selected_values = selected
  end

You wrote it twice (for selected and disabled) and they exactly the same. =)

Yeah, I'm ready to extract those two blocks of code but was waiting for some more feedback on the general principle first.

With regard to passing a hash instead of the extra parameter, do you mean repurpose the selected parameter so that it can be a selected value, an array of selected values, or a hash for both selected and disabled values?

I don't know if that feels right... Then again, it doesn't feel quite right adding the extra optional parameter to those methods either.

Anyone else think this would be a better approach?

OK, I've reworked this patch, rebasing with edge and removing some of the duplication.

I've also worked up an alternative which doesn't change the API and instead duck-types the selected parameter so that you can pass in a hash if you want to specify disabled option tags.

Personally, I'm not convinced by the duck-typing, but it does have the advantage of not adding any more parameters (optional or otherwise) to the methods.

Here's the second duck-typing method patch.

Would be good to get this into 2.3, any suggestions on moving forward with this?

OK, here's an updated patch with some no-frills documentation. Hopefully someone with better writing skills and docrails access will spruce them up!

With 2.3 RC1 out, is this going to slip to the next release? Otherwise, let me know if there is anything else needed from my end to get this patch into core before 2.3 goes official.

Tekin,

Sorry for the delay, this one fell of my radar. It doesn't apply cleanly at present, but if you can rebase it it looks good to me.

Also, perhaps split the dummy_posts change into another changeset, took me a while to separate out the changes in the patch from the (nice) refactoring.

OK, new patch, rebased with edge, with separate commits to make things clearer. Much nicer!

Here's a patch for the changelog so it's not overlooked.