I'm not arguing with you either, and I'm not discrediting your method.
I was intrigued to know more because we had similar requirements and
went in different directions. I see the benefits of your method. It is
without a doubt the fastest and most efficient of the two.
> With the metadata plugin, I did:
> <div id="div1">
> <script type="application/json">
> {field1: 'value1', field2: 'value2'}
> </script>
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.
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.
Thanks,
Diego A.
On Sep 22, 10:05 pm, "Erik Beeson" <[EMAIL PROTECTED]> wrote:
> > I didn't know about logical operator short-circuiting, thanks for the
> > info - it's good to know.
>
> > But this obviously wasn't in place on my tests or I wouldn't have got
> > the results I did. So I don't think logical operator short-circuiting
> > is a reliable enough solution to this problem...
>
> Why wouldn't it be reliable?
>
> I considered doing exactly what you did - using a global variable to
>
> > store metadata - but even then don't you have 2 issues with that?
>
> With the metadata plugin, I did:
> <div id="div1">
> <script type="application/json">
> {field1: 'value1', field2: 'value2'}
> </script>
> ...
> </div>
>
> Now I do:
> <div id="div1">
> <script type="text/javascript">
> myNamespace.myData['div1'] = {field1: 'value1', field2: 'value2'};
> </script>
> ...
> </div>
>
> 1. lazy programming because you end up evaluating things before you
>
> > actually need them
>
> My "data" is generally just simple key/value pairs, there's little
> "evaluation" going on in terms of processing. In terms of storage, I think
> it's more efficient because with the metadata plugin, the data is stored
> first in the DOM, and then again as JavaScript objects once you access the
> data. Plus I think the overhead of all of the processing that the metadata
> plugin does is slower than just accessing a variable.
>
> 2. a nightmare mapping the metadata to its owner elements?
>
>
>
> In my case, I have a guaranteed unique ID for each chunk of data, so access
> goes from $('#id')[0].data with the plugin to myNamespace.myData['id'] the
> way I do it now.
>
> But I'm not arguing that you shouldn't use it. If it's working for you,
> that's great. My main comment was that you could use the short-circuiting.
>
> --Erik
