Mike Dershowitz wrote:
options = {:onclick => "new Effect.Fade('duedate'); return false;"}) %>
return true ?
I think that lets the click event bubble up to the default click handlers instead of stopping the chain. The default handler is what does the checking/unchecking.
_Kevinj
Mike Dershowitz wrote:
radio_button_tag ('duedate', 1, checked = false,
options = {:onclick => "new Effect.SlideDown('duedate'); return false;"})
I forgot to point something out about that style.
Ruby functions can't see variables on their command lines written like checked=
The value goes in, but the name of the variable on the left side of the assignment does not. Ruby doesn't care if you wrote monkey= or spider= or nothing there. So prefer nothing; programs should have as few moving parts as possible!
Mike Dershowitz wrote:
I was wondering about that - so thanks for clearing it up for me. Looks like the left-hand of the assignment is only helpful for the programmer and not for the framework. So whatever belongs in that position when the appropriate method is called is what rails is expecting.
So that begets the question of how to handle empties or can you re-order if you use name assignments. Based on what you said here, seems like not? Is that correct?
Inferior languages use two systems to name arguments - Hashes/Maps, and named parameters. So such a language, with a Ruby-like syntax, would permit this:
foo( :arg1 = 'bar', { :arg2 => 'baz' } )
That requires a foo with this signature:
foo(arg1, aMap)
Ruby splits the difference by not using two systems there, only one. Using only one system, instead of two, is always a Good Thing - it's an example of the DRY principle, Don't Repeat Yourself.
All Ruby arguments are positional, and arg1 may not follow aMap. But Ruby allows you to leave out the map notation {}. So this...
foo('bar', :arg2 => 'baz')
...is the only way to call foo(arg1, aMap). arg1 is not optional, but arg2 is.
This technique returns incredible control to the function author. She or he can detect which argument is a Hash and proceed accordingly. A function could take only a map, for example, and the caller can pass named arguments in any order so long as their names match.
Now read up on Hash#merge and Hash#update. You handle an empty by checking if aMap[:arg2] is nil, or simply by merging a default Hash into aMap before pulling its arguments. Or updating - I forget which.
Mike Dershowitz wrote:
radio_button_tag ('duedate', 1, checked = false,
options = {:onclick => "new Effect.SlideDown('duedate'); return false;"})
Another answer. Rails authors who cram huge long statements like that together should be lined up and smacked. options= there is a best-practice when you simply use it as an argument, to break up long lines:
options = {:onclick => "new Effect.SlideDown('duedate'); return false;"})
radio_button_tag ('duedate', 1, false, options)
Now you can actually see where expressions begin and end!
The other way around, options= inside the method call, is also bad because I might think options is used somewhere below, and it isn't.
