We are having problems with this line on IE7. I have an empty DOM node that I've inserted into the page with a jQuery template. I call empty() on it, and-- on IE7-- it croaks. Actually, it seems like it works once, but then not the second time, but I don't have a good Javascript tracing setup working, and using alerts() doesn't work, since this method appears to be called 100s of times.
I'm getting the IE equivalent of a NPE. In our case, it appears that cache[id] is not set, even though pvt and id are, and therefore we are getting an error.
Anyway, I am able to "fix" the problem by substituting "(!cache[id] || !cache[id][internalKey])"
I have no idea if this is right.
Would appreciate some guidance. I'm not sure what is actually necessary to reproduce and test, since I'm not familiar with the intent of this code.
This isn't a good place to ask for support. Since the problem surfaces with .template() you should ask about it there. Regardless, whoever tries to track it down will need a reduced test case in order to debug it.
return;
}
// Get the data from the object directly
if(!isNode){
cache=elem;
if(!id){
// Only DOM nodes need a new unique ID for each element since their data
This means that currently the event binding code, for example, is adding jQuery expandos to plain objects that are not of type function, and therefore show up on JSON serialized objects. It is inconsistent with this comment in the event.add method:
if ( typeof events === "function" ) {
// On plain objects events is a fn that holds the the data
// which prevents this data from being JSON serialized
// the function does not need to be called, it just contains the data
Suggested fix:
if ( !cache[ id ] ) {
// cache[ id ] = {};
cache[ id ] = isNode ? {} : function(){};
}
}
// Avoid generating a new cache unless none exists and we
// want to manipulate it.
// An object can be passed to jQuery.data instead of a key/value pair; this gets
Have you tested the impact on performance of such change? You are adding one more function call when using jQuery._data() instead of jQuery.data().
In places were performance is critical, we should probably use the old jQuery.data with true as the last argument, shouldn't we?
@lrbabe, our intent with jQuery._data() is to prevent name collisions between internal jQuery data and external data attached by user code or plugins. Plugin developers should continue to use jQuery.data() or $().data() but of course they can use their own conventions to avoid collisions there, such as prepending "myPlugin" to the name of each data item or creating a master "myPlugin" object that contains all the data.
Thank you for these explanations @dmethvin.
What about always passing true (or 1 if we're concerned about filesize) as a fourth param instead of using _data and adding unnecessary function calls?
@lrbabe, we discussed and didn't think an extra function call would make too much difference. If you'd like to create some benchmarks to show a performance hit, we could take a look.
We are having problems with this line on IE7. I have an empty DOM node that I've inserted into the page with a jQuery template. I call empty() on it, and-- on IE7-- it croaks. Actually, it seems like it works once, but then not the second time, but I don't have a good Javascript tracing setup working, and using alerts() doesn't work, since this method appears to be called 100s of times.
I'm getting the IE equivalent of a NPE. In our case, it appears that cache[id] is not set, even though pvt and id are, and therefore we are getting an error.
Anyway, I am able to "fix" the problem by substituting "(!cache[id] || !cache[id][internalKey])"
I have no idea if this is right.
Would appreciate some guidance. I'm not sure what is actually necessary to reproduce and test, since I'm not familiar with the intent of this code.