Interesting radio button behavior with "onclick"

Rails
1

Hello:

I have radio buttons like this:

<% fields_for :goalhist do |g| %>

<%= radio_button_tag ('duedate', 0, checked = false, options = {:onclick => ""}) %>   Start now
<%= radio_button_tag ('duedate', 1, checked = false, options = {:onclick => ""}) %>   Already started!
<% end %>

So, they behave fine; but, what’s interesting is that when I popuulate
the onclick methods, the checking of the radio buttons no longer
responds. If I leave those methods unpopulated, they perform fine.
Here’s my populated code:

<% fields_for :goalhist do |g| %>

<%= radio_button_tag ('duedate', 0, checked = false, options = {:onclick => "new Effect.Fade('duedate'); return false;"}) %>   Start now
<%= radio_button_tag ('duedate', 1, checked = false, options = {:onclick => "new Effect.SlideDown('duedate'); return false;"}) %>   Already started!
<% end %>

Any ideas? Only thing else you might need to know is that the
“fields_for” exists within another “form_for” tag.

Thank you so much in advance!

Mike

2

Mike D. wrote:

options = {:onclick => “new Effect.Fade(‘duedate’); return false;”}) %>

return true ?

–
Phlip
Redirecting... ← NOT a blog!!!

3

Phlip wrote:

Mike D. wrote:

options = {:onclick => “new Effect.Fade(‘duedate’); return false;”}) %>

return true ?

–
Phlip
Redirecting... ← NOT a blog!!!

Yep, that did it! Thank you so much!

Any idea as to why?

Mike

4

On Feb 3, 4:40 pm, Mike D. [email protected]
wrote:

Yep, that did it! Thank you so much!

Any idea as to why?

Mike

–
Posted viahttp://www.ruby-forum.com/.

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

5

Mike D. 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!

–
Phlip
http://c2.com/cgi/wiki?ZeekLand ← NOT a blog!!

6

Phlip wrote:

Mike D. 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!

–
Phlip
http://c2.com/cgi/wiki?ZeekLand ← NOT a blog!!

Phlip:

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?

7

Mike D. 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.

–
Phlip
Redirecting... ← NOT a blog!!!

8

Mike D. 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.

–
Phlip
Redirecting... ← NOT a blog!!!