Try putting debugger or console.log("xyz") inside of your onload handler. If
you don't see it break at the breakpoint or console output "xyz" when you click
to a new page, then it isn't re-attaching.
I'm actually not the person to ask about using turbolinks (since I'm not a big
fan), but it sounds like there's a way to detect the change event and re-call
the function that makes the attachment.
-Jason
On Jun 18, 2014, at 6:55 PM, Damián M. González <[email protected]> wrote:
> Jason Fb wrote in post #1150072:
>> What exactly (please paste code examples) by "comes to this view from
>> another view" ?
>
> I'm in an HTML page, I click an anchor HTML element(<a>) which takes me
> to another HTML page.
>
>> If the page is reloaded check to make sure your onload handler is
>> re-attached correctly (you can do this with simple debugging or console
>> statements inside of your onload function)
>
> It's not re-attaching. I'm thinking that turbolinks has something to
> do.
>
>> If you have some kind of ajax setup (like some of the default Rails
>> stuff), then parts of the page might be getting replaced with new HTML
>> content (Like your my_element). When that happens, the HTML is replaced
>> and the new html elements do not have the click handler attached to them
>> (and your onload is not re-run).
>
> I don't know how can I check if this is happening?
>
>> To keep things the way they are, try using jQuery 's on method
>> (http://api.jquery.com/on/), which you should attached to a parent of
>> the object that is getting replaced by ajax -- not the actual link
>> itself.
>>
>> Better yet, think about learning Backbone, Ember, or Angular. The way
>> you are working with Javascript works OK in very tiny apps, but breaks
>> down quickly in larger apps with a lot of client-side interactivity.
>> Personally, I haven't written javascript in the style you are writing it
>> (big, global class-bsaed targets that attach click handlers during the
>> window's onload) since about 2009.
>>
>> If you are using turbolinks you have to re-attach all your click
>> handlers after the page content is replace, as discussed with detecting
>> the page change event.
>
> I'll take a look at how turbolinks work.
>
>> Like I said, in a small app you will get away with this but in a larger
>> app you will drown in a nightmare of page change event binding and
>> handler attachment bugs. This is why generally Javascript developers I
>> know stay away from this style of coding and prefer a more robust
>> think-client approach like the ones I mentioned. Obviously, detecting a
>> change event may just be a small fix and learning a whole new way to
>> write code is a bigger task.
>
> Thanks for the advices Jason, very helpfull.
>
> --
> Posted via http://www.ruby-forum.com/.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rubyonrails-talk/51f725f6f4331357a22296162623c4a1%40ruby-forum.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/rubyonrails-talk/954F5B13-F8DC-4FE9-95A7-185A48BB99EF%40datatravels.com.
For more options, visit https://groups.google.com/d/optout.
