Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualUbik

Posted 09 May 2013 - 11:44 AM

The JavaScript comment was there to draw attention to how the selectors have changed between the examples.

 

In the original example there was $('#result a'), which would return the links within the #result element. The modified example was split into $('#result') which returns just the container element. The on() after it, used to bind the click handler, results with the handler being actually bound to the #result element. That is why the handler would survive even if the contents of the container were replaced by load(). The second parameter to on() is just 'a', and acts as a second search filter that is executed against (or actually within) the results of the "regular" jQuery query earlier on the line that was used to find #result. It is the thing that makes sure the click handler you are binding to #result is actually only executed when a link in #result is being clicked.

 

Regarding the second question, maybe I should break the code down a bit. It could have been done like this:

 

 

$('#result').on('click', 'a', function() {
    var url = $(this).attr('href');
    $('#result').load(url);
    return false;
}); 

 

The click handler has a special variable named this defined within it, and it refers to the element that was clicked. However, you can't use jQuery functions against it directly, you need to use the $(this) form. With that, the attr('href') is called, to get the URL the clicked link is pointing at. That URL is then given to load(). If "page.php" was used, any link within the loaded content would ever only point to page.php. Your original post suggests that the links could point to other pages as well. Even if they didn't, hardcoding the URL is not recommendable, when you can just make the link have a proper URL in its href and use it.

 

Edit: Addition to the first part. There is a parallel with the "two-part" selection with jQuery's function find(). Doing $('#result a') is functionally equivalent to $('#result').find('a'). They both return the links within #result. However, with on() there is an important difference: the selector given to it is not executed immediately. Only when the #result receives a click (remember, the handler is actually bound to it) it runs the second selector to see if the click hit a matching element within the container. In this case, a link.


#2Ubik

Posted 09 May 2013 - 11:11 AM

The JavaScript comment was there to draw attention to how the selectors have changed between the examples.

 

In the original example there was $('#result a'), which would return the links within the #result element. The modified example was split into $('#result') which returns just the container element. The on() after it, used to bind the click handler, results with the handler being actually bound to the #result element. That is why the handler would survive even if the contents of the container were replaced by load(). The second parameter to on() is just 'a', and acts as a second search filter that is executed against (or actually within) the results of the "regular" jQuery query earlier on the line that was used to find #result. It is the thing that makes sure the click handler you are binding to #result is actually only executed when a link in #result is being clicked.

 

Regarding the second question, maybe I should break the code down a bit. It could have been done like this:

 

 

$('#result').on('click', 'a', function() {
    var url = $(this).attr('href');
    $('#result').load(url);
    return false;
}); 

 

The click handler has a special variable named this defined within it, and it refers to the element that was clicked. However, you can't use jQuery functions against it directly, you need to use the $(this) form. With that, the attr('href') is called, to get the URL the clicked link is pointing at. That URL is then given to load(). If "page.php" was used, any link within the loaded content would ever only point to page.php. Your original post suggests that the links could point to other pages as well. Even if they didn't, hardcoding the URL is not recommendable, when you can just make the link have a proper URL in its href and use it.


#1Ubik

Posted 09 May 2013 - 11:10 AM

The JavaScript comment was there to draw attention to how the selectors have changed between the examples.

 

In the original example there was $('#result a'), which would return the links within the #result element. The modified example was split into $('#result') which returns just the container element. The on() after it, used to bind the click handler, results with the handler being actually bound to the #result element. The second parameter to on() is just 'a', and acts as a second search filter that is executed against (or actually within) the results of the "regular" jQuery query earlier on the line that was used to find #result. It is the thing that makes sure the click handler you are binding to #result is actually only executed when a link in #result is being clicked.

 

Regarding the second question, maybe I should break the code down a bit. It could have been done like this:

 

 

$('#result').on('click', 'a', function() {
    var url = $(this).attr('href');
    $('#result').load(url);
    return false;
}); 

 

The click handler has a special variable named this defined within it, and it refers to the element that was clicked. However, you can't use jQuery functions against it directly, you need to use the $(this) form. With that, the attr('href') is called, to get the URL the clicked link is pointing at. That URL is then given to load(). If "page.php" was used, any link within the loaded content would ever only point to page.php. Your original post suggests that the links could point to other pages as well. Even if they didn't, hardcoding the URL is not recommendable, when you can just make the link have a proper URL in its href and use it.


PARTNERS