I think we are talking about two different effects here. This can definitely
be subtle so it's good to have someone ask the question.
> var cell = $(e);
> var cellParent = cell.parent();
> var cellParent2 = cell.parent();
> ...
> Further digging seems to hint at the fact that every time
> cell.parent() is called, it's the equivalent of cell = cell.parent()
> and as such the original value of cell is lost.
Most jQuery methods are designed to be chainable; they return the original
object as the return value so that a subsequent method can be called on it.
That is true of the .parent() method. So what's happening is that you have
created three different aliases for the same object! The two .parent()
method calls are modifying the internal state of the *same* jQuery object
and returning that object back to you. It's the internal state of the jQuery
object that remembers the selected nodes, not the return value.
To create a brand new jQuery object that contains the parent, without
changing the jQuery object with cell, you could use one of these:
var cell = $(e);
// Copy cell object and then get parent in the copied object
var cellParent = $(cell).parent();
// XPath expr navigates to parent using cell as the context
var cellParent2 = $("..", cell);
The $(cell) usage for creating a copy of a jQuery object is described in the
documentation for $(), but navigating the jQuery site I had a hard time
finding the XPath documentation to explain the second example.
"Destructive" methods like .parent() that change the jQuery object's
selected nodes always push the previous list of selected nodes onto an
internal stack that can be popped with the .end() method. So in the case
above, the jQuery object stored in cellParent has a pushed copy of the DOM
node selected by cell (the same DOM node originally passed in by e) that you
can get to if you use .end(). The problem you originally mentioned above
would have occurred whether destructive methods worked this way or not. It's
just a difference of whether the object "stacked" the previous (two) sets of
nodes.
> Maybe someone can shed some light on specific situations where
> the destructive method saves considerable amounts of code.
> I can definitely see how it'd be useful--do some work on the parent,
> then end(), then do some work on the element itself--but is this
> functionality used frequently?
It's useful when you get comfortable with chaining because it avoids having
to declare and use extra variables. I would actually prefer an explicit
push/pop approach myself because the creation of the stacked nodes is too
implicit and the stacked node references are cumbersome to eliminate if you
don't want them.
Sounds like this was (painfully!) reduced from some more complex code. Maybe
there is a jQuery-ish way to do it? You can avoid trouble with aliases if
you chain methods, since you aren't storing the object in a variable.
_______________________________________________
jQuery mailing list
[email protected]
http://jquery.com/discuss/
