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 -- Nik Wakelin munkywrench@gmail.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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? On 9/10/07, DHH <david.heinemeier@gmail.com> wrote:> > > 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. > > > > >-- Nik Wakelin (027) 424 5433 munkywrench@gmail.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---