On 20 Oct 2009, at 13:09, Eduardo Bueno wrote:
>> You realize this is a client-side interaction, which means Javascript
>> no matter how it's packaged? :-)
>>
> Yes, but like server-side code, javascript must be propper coded, and
> explicit onclick event declaration is wrong.
It's not wrong, it just looks ugly and can be very verbose if you put
it on every single row, so a more generic approach is preferrable to
say the least.
You have a couple of options:
- Either go completely event delegated, mixing in a library
specifically designed for this like NWEvents can greatly benefit your
application, we use it for everything in our apps and has greatly
improved performance, works seamlessly even when replacing or adding
new parts to the page that have to exhibit similar behavior and
reduced code clutter. It's a bit like jQuery's live function, and it
supports non bubbling events too, like focus and blur on form elements
and form submission
- Or you can put the click event observer on the table itself. If you
add new tables that need highlighting via ajax, you'll have to attach
a new observer to that one too, as well as clean up observers before
destroying elements on the page.
In both cases, inspect the event.target (what element was actually
clicked), then go .up('tr') and put the highlight class on the row. If
that needs to be saved in the model, just fire an Ajax.Request from
your javascript highlight method.
The simple fact of the matter is that you'll have to write custom
javascript and not rely on Rails' built-in helpers to get a performant
and clean solution.
Best regards
Peter De Berdt
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
