On Sun, Oct 18, 2009 at 11:06 AM, Robert Katić wrote:
>
> Andrea, IE is nor open source, so I can not be sure if "new Number" is
> 100% safe as element property.
Robert, I have already posted a test. In IE if you store a primitive, it's
exposed, if you store an instanceof Object, it's not.
Same
I noticed some typo so here corrected versions:
$.data(elem, readOnly) -> http://pastebin.com/fa43da97
$.data(elem, name) -> http://pastebin.com/f758b264
$.data(elem, name, data) -> http://pastebin.com/f3deb2895
If I am the only one to think that getting a value would not causing
data object cre
Andrea, IE is nor open source, so I can not be sure if "new Number" is
100% safe as element property.
Some testing if it produces memory leak would help here.
On Oct 18, 11:18 am, Andrea Giammarchi
wrote:
> Robert new Number is simply for a reason, in IE:
>
> var div = document.createElement("d
I played a little on some variations of $.data() API and concluded
with these:
$.data(elem, readOnly) -> http://pastebin.com/f323becaa
$.data(elem, name) -> http://pastebin.com/f498f9a65
$.data(elem, name, data) -> http://pastebin.com/f6b474da8
I didn't tested/profiled it yet, but if we consider
Robert new Number is simply for a reason, in IE:
var div = document.createElement("div");
div.whatever = 1;
alert(div.outerHTML);
//
div.removeAttribute("whatever");
div.whatever = new Number(1);
alert(div.outerHTML);
//
if there are no side effects I can't see why DIV should be dirty in IE. A
Yes there is a big error in my code. Here is new one
http://pastebin.com/d66929de4
On Oct 18, 1:27 am, Robert Katić wrote:
> If I was not clear enough here are some codehttp://pastebin.com/m14c0aa3b
>
> PS: For now, I am not sure if new Number(...) is necessary and that it
> is safe enough.
>
>
If I was not clear enough here are some code http://pastebin.com/m14c0aa3b
PS: For now, I am not sure if new Number(...) is necessary and that it
is safe enough.
On Oct 18, 1:05 am, Robert Katić wrote:
> I am certainly in favor to that that $.data(elem) returns data object
> instead of id.
>
>
I am certainly in favor to that that $.data(elem) returns data object
instead of id.
I would like that $.data() will not handle getting/setting too, but
then we would probably consider how to handle getting without
generating the data object. Maybe an $.data(elem, true) to get data
object without
Actually, no leaks at all, almost the same elapsed time, and weird enough
apparently leaks are with Firefox and expando integer.
This is the test I have used, please note it could be stressful via Firefox:
onload = function(){
alert("snap"); // use alert/snaps to monitor memory usage via task
expando is removed when necessary while new Number is an instance of Object
but basically just an integer, I can't spot side effects here but if you
have a test about this I'll have a look.
On Sat, Oct 17, 2009 at 3:31 PM, Dave Methvin wrote:
>
> > #38 elem[ expando ] = new Number(id);
>
> I
> #38 elem[ expando ] = new Number(id);
I thought there were memory leaks when attaching Javascript objects to
DOM expandos in IE.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To po
John, I had a quick look into data. Basically a simple improvement could be
at line 38 of data.js
#38 elem[ expando ] = id;
should probably be
#38 elem[ expando ] = new Number(id);
This will simply avoid dirty string element representation in IE (try with
outerHTML or parent innerHTML)
> Of course, although it would simplify the $.data() implementation
> (speed performances too) it would breaks compatibility with many
> existent plugins. However, $.data() in 1.4 will breaks it already...
If developers want to switch to this style they're absolutely welcome
to (in fact, we alrea
On Wed, Oct 14, 2009 at 1:18 PM, Mark Gibson wrote:
>
> Thanks John, that makes complete sense, I too am not sure why jQuery
> UI doesn't use a counter either.
>
Thanks for the patch. Fixed.
http://groups.google.com/group/jquery-ui-dev/browse_thread/thread/7e1fe2a53bf0c7d3
- Richard
--~--~---
Hi Robert,
that's just a proof of concept easily re-adaptable for the new jQuery data.
Main differences:
1 - rather than primitive number, the expando is associated to a Number
instance. This avoids dirty string representation ( specially for those that
need/parse directly generated HTML ... in f
Hi Andrea. Nice solution.
Using array instead of object is a nice speed boost (at least on Fx
3.5).
However, I suppose that an _index will not be necessary in jQuery.
Honestly I consider that $.data() would be exactly as your $.proxy()
(the simpler one).
Now that $.data returns the data object of
Hi John. This expando and node object relations is something I am kinda
dealing with every day.
I have not read jQuery 1.4 solution yet but I wonder if my latest post,
created "for this occasion", could give jQuery some good advice/suggestion.
http://webreflection.blogspot.com/2009/10/dom-node-pro
Thanks John, that makes complete sense, I too am not sure why jQuery
UI doesn't use a counter either.
In my own code I have a plugin that generates an id if one is not
already present on an element:
(function($) {
var prefix = 'id' + (+new Date()) + '-', count = 0;
// Get the id of an element,
Hi Mark -
This was intentional. We could no longer guarantee that an ID would be
attached for an element at all times (which is what was done before).
Additionally calling that method would attach an expando and object to
an empty element - even if no data needed to be stored (which is bad).
Almo
19 matches
Mail list logo
