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?