If you need to store just key/value pairs mapped to an element, why
not use the new jQuery.data method (aka "Expando Management")?  I'm
using this in a caption plugin I'm writing to store the id of the
caption element to its image.  The code is fast and has been working
super smooth for me, I prefer it to a global lookup table.  It's easy
to miss the documentation for it, I only see it here:

http://docs.jquery.com/Release:jQuery_1.2/Internals

Charles
doublerebel.com

On Sep 23, 4:31 am, "Erik Beeson" <[EMAIL PROTECTED]> wrote:
> > I do it like this:
> > <div id="div1" class="{field1: 'value1', field2: 'value2'}"></div>
> > It costs more performance-wise, but I think it is worth it in terms of
> > flexibility and clarity, which is why I went out of my way to fine-
> > tune the metadata plugin.
>
> I went with the nested script block because I think it's the only way that's
> actually valid HTML. The custom attribute version could at least be valid
> XHTML (I think?), but the "data in the class attribute" version makes me
> cringe to think of what the poor browser must be trying to do with that data
> (like look for a CSS definition for a class called "{field1:" or some such).
> I know it works, it just pains me a little to see, and I couldn't bring
> myself to use it.
>
> About short-circuiting, I said it was un-reliable because it wasn't
>
> > being used by my browser. Now I've looked over the original code and
> > realised that the original statement was:
> > if ( this.nodeType == 9 || $.isXMLDoc(this) || this.metaDone ) return;
> > ...when it should have been...
> > if ( this.metaDone || this.nodeType == 9 || $.isXMLDoc(this) ) return;
> > ...in order for short-circuiting to work. Indeed, this would have
> > stopped $.isXMLDoc(this) being executed over and over again.
>
> Right. I'm not sure why metaDone isn't checked first anyways. Regardless of
> the addition function call(s), it seems like the logical thing to check
> first: "if we haven't already done this, and it isn't X or Y... then do it".
> Not "if we shouldn't do it because of X, or if we shouldn't do it because of
> Y, or if we shouldn't do it because we already have."
>
> It's probably worth opening a bug report for these issues that you've raised
> so that they don't get lost.
>
> --Erik

Reply via email to