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 few words the expando won't be in the layout ) 2 - being a callback the association is created only once and only if necessary, no node<-->object relaton by default As you said new data already breaks jQuery based plug-ins so maybe you should consider to adopt a "perfect strategy" in order to avoid changes like this in the future. I'll have a look soon in your implementation maybe suggesting a complete solution for jQuery case. Regards On Fri, Oct 16, 2009 at 4:04 AM, Robert Katić <robert.ka...@gmail.com>wrote: > > 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 an element, it doesn't need > to handle setting/getting values too. > > $.data(node)[name] = value; > > is even more concise then: > > $.data(node, name, value); > > 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... > > > On Oct 15, 3:43 am, Andrea Giammarchi <andrea.giammar...@gmail.com> > wrote: > > 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-proxy.html > > > > Regards > > > > On Wed, Oct 14, 2009 at 5:40 PM, John Resig <jere...@gmail.com> wrote: > > > > > 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). > > > Almost universally the use of $.data(elem) was used to get at the > > > entirety of an element's data collection - which is what is now > > > returned from $.data(elem) instead. > > > > > Looking at the tabs code it looks like they're using it to generate a > > > unique ID (but it's not clear as to why they need $.data for this - > > > they could, just as easily, keep a global ID counter and assign it to > > > the element if it doesn't have one, already. There's no need to attach > > > an entire data object just to get at that information. > > > > > As it stands the next version of jQuery UI will require jQuery 1.4 so > > > this is definitely one place where we could make that clean break. If > > > it does become problematic, though (especially for other plugins), > > > then we could look into ways of changing it. > > > > > --John > > > > > On Wed, Oct 14, 2009 at 10:24 AM, Mark Gibson <jollyt...@gmail.com> > wrote: > > > > > > Hi, I've noticed that the behaviour of $.data() has changed in > 1.4pre, > > > > > > $.data(elem) no longer returns the cache id, it returns all the data > > > > items or null. > > > > this will probably break a lot of code (already breaks jQuery UI > Tabs) > > > > > > Is this intentional, or a bug? > > > > > > - Mark. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
