On Jan 5, 2007, at 3:49 PM, Jan Svitok wrote:

> On 1/5/07, James Edward Gray II <james / grayproductions.net> wrote:
>> On Jan 5, 2007, at 11:40 AM, Josselin wrote:
>>
>> > I have an account_controller object ..  when the  user 'submit the
>> > form, the 'confirm' method is called, but 2 buttons can confirm
>> > so I have to check upon the submit value... which I do
>> > each submit button CANNOT call a different method in my object..
>>
>> Are you sure about that?  ;)
>>
>> class AccountController < ApplicationController
>>    # ...
>>
>>    def confirm
>>      send("confirm_for_#{params[:submit_button]}")
>>    end
>>
>>    # ...
>>
>>    private
>>
>>    def confirm_for_button_one_name
>>      # ... whatever ...
>>    end
>>
>>    def confirm_for_button_two_name
>>      # ... whatever ...
>>    end
>>
>>    # ...
>> end
>>
>> Just a thought.  Not that there is anything wrong with your case
>> statement though.
>>
>> James Edward Gray II
>
> I wanted to write that this is not a good example -- the case
> statement would be more readable and probably even faster. Then I
> realized that the situation changes if somebody wants to subclass this
> and add another button. Just add another method and it's done. With
> the case statement it wouldn't be that easy.
>
> Then I was thinking that if the params[:submit_button] contained the
> whole method name, the confim method would be nicer. The drawback is
> that the way it is now  provides a bit of security -- it's not
> possible to call any method, just a limited subset. It would be
> possible to check whether the param is in a specified set, but that
> would break extensibility (or a means to extend the set would be
> needed).

It's just one thought.  There are times when it is very powerful  
(like when building state machines), but this probably isn't one of  
them and there is nothing wrong with using a case statement here, in  
my opinion.

James Edward Gray II