link_to_remote API (Patch #9505)

Hi All,

I've just uploaded a small patch to the API for passing html options
(classnames etc.) to link_to_remote.

The ticket has a better explanation:

http://dev.rubyonrails.org/ticket/9505

I think it might warrant a little discussion here as I assume the
second param (options, html_options) is so that link_to_remote is
similar (API-wise) to link_to (which takes two parameters).

I personally prefer the option of passing an :html key over passing
two hashes in any case, and I'm willing to write patches as such. I'd
be interested in other people's views though (and what the core team
thinks).

Thanks!

Nik Wakelin

I personally prefer the option of passing an :html key over passing
two hashes in any case, and I'm willing to write patches as such. I'd
be interested in other people's views though (and what the core team
thinks).

I think that's reasonable for methods that have option hashes where
urls are only part of the content. But not for methods link link_to,
which has an option hash that's purely to specify the url. With named
routes, we've come to link_to(person.name, person, :class =>
"some_person"). Which is a lot better than link_to(person.name, :url
=> person, :html => { :class => "some_person" }). But that's not what
you're doing here, so I'm +1 on the current patch.

Agreed - link_to(person.name, person, options_hash) is much nicer.

I've looked around and I can't see any other places in which this
cleanup could be applied, any suggestions?