jQuery And Script Tags As Data Containers

Posted June 5, 2009 at 9:59 AM by Ben Nadel

Tags: Javascript / DHTML

Reader Comments

Maybe I'm being thick, but how does this help you more than a document/window scoped JSON literal?

<script type="text/javascript">
var metadata = [
"Plain text in script tag.",
"More plain text in script tag."
];
</script>

@Rick,

The difference is that the script tags can be contextual to the HTML in which they are defined. For example, I could put a script tag inside each row of a data grid that contains information like ID that can be used to then make further row-related AJAX calls.

If you were just going to use window-scoped JSON, each tag might overwrite each other.

Very Cool. I love jQuery.

Do you envision being able to use this with something like cfquery to load database information into jQuery, or is this strictly for text/XMl type stuff?

Thanks,

JW

@James,

I picture it with being able to padding item-specific data along with HTML. So, for a query, if we were to generate a HTML table based on the data, I might pass a Script tag with *each* row with record-specific information.

@Ben

Wouldn't you just use input type="hidden" for that type of info? You get the same benefits of contextualization and DOM-based storage/parsing that you're looking for. It seems like the script solution is .... hacky.

@Roland,

Yes, using a hidden input is a very nice option ... when you are inside of a FORM element. Also, I am not sure how I would feel about passing JSON data inside of a hidden input value. Could get messy and would be hard to write with all the quote / line-break escaping.

I can definitely see that being an issue.

I don't know - something about Hal's approach just makes me feel dirty :)

@Roland,

Hal used the CSS-storage route of the metadata plugin. I agree with you that this feels a little kludgey. I also am not crazy about adding custom name-spaced HTML attributes, like:

<div app:id="3">

... which I believe the metadata plugin can also handle.

That's why I really like the SCRIPT tag version - it doesn't mess up or "override" any existing attribute usage. Plus, because the type attribute of the Script tag allows you define the mime-type of the contained data so we're being really explicit about what the data is and how it can be used.

To me, that feels quite clean.

I absolutely agree that the script tag version is less dirty :)

I was going to suggest maybe just using comments, but it looks like you beat me to it!

http://www.bennadel.com/index.cfm?dax=blog:1563.view

Seems like it's more difficult to impliment though.

I've just recently been utilizing jQuery too, and it's been very interesting. Lots of ways to do things, and no real best practices have been developed. Glad to see I'm not plumbing the depths alone!

@Roland,

I like the comment approach, but I like the script tag even more as I think the "intent" of the script tag is more properly aligned with data contained within it than with HTML comments.

"This metadata() plugin seems pretty cool, so I looked it up to see how it worked (I like to dig into cool things)."

Funny, I could have sworn Todd Raffery and I tweeted you about the metadata() plugin when you were trying out the data() function in jQuery many moons ago. Weren't you listening?? :)

@Brian,

That sounds about right :) I guess, what I got jazzed up about this time was the use of the Script tag more than anything else.

Speaking of which, I was just about to ask you whether you wouldn't agree that the data( ) function seems a lot more maneuverable and productive than this approach?

To me having to contextualize the information you're storing with a script tag and mime type feels so verbose it kind of stings. It's just as easy to inject an invisible span or other container to keep yourself in the usual.

Before I found out about data( ) ( from your blog I might add ), I used to just pop invisible spans sibling or child to whatever structures I wanted to operate on and it worked beautifully.

Ex:
<div id="scripts">
<script type="text/plain">
Plain text in script tag.
</script>
<script type="text/plain">
More plain text in script tag.
</script>
</div>

Becomes:
<div id="scripts">
<span>Plain text in script tag</span>
<span>More plain text in script tag.</span>
</div>

And you'd just use the html( ) method ( just like you would with your script tags ) to retrieve the data.

Interested to hear your thoughts. Hopefully I haven't missed the point, which seems like to store data contextual to some other data in order to simplify identification and communication across an application.

@David,

I think from a usability standpoint, there is no real difference between the SPAN approach and the SCRIPT approach - in the end, you're just pulling html() out of either of them.

But, there are a few things I like about the SCRIPT approach over the SPAN approach:

* Script is inherently not rendered (Span you would have to hide via CSS).

* Script has an inherent mime-type definition (Type attribute) which could be used to programmatically consume (ex. if type is "application/json", eval() data before returning it, otherwise return as string). (Span has no inherent data type other than string).

So, that's why I am warming up to this a lot. But, like I said, ultimatley, you are just getting data via html().

Once you have that data, though, I definitely agree that you would use the data() method to bind it to a DOM element so that it could be re-addressed later without re-parsing.

I put together an example of this in conjunction with an AJAX call to return HTML table data:

http://www.bennadel.com/blog/1604-Using-Script-Tags-As-Data-Contains-In-AJAX-Powered-jQuery.htm

There were some oddities in the way the script tags get placed during the append() method.

One of my favorite methods of the metadata plugin is with SerializeJSON and your favourite QueryToStruct implementation. If you are iterating through a query, it is easy to very tightly couple your data with your dom elements and spare yourself additional traversal later on when you need access to additional info from the query.

John Resig put together a pretty interesting implementation of micro-templating using the mime type on script blocks...
http://ejohn.org/blog/javascript-micro-templating/

--adam

@Adam,

I think I've seen that post before - but long before I really understood using Script tags as data containers. I will definitely re-examine it, thanks.

Hi!

I would like to know how would you use this approach if u needed to store data, for example, for each option in a select box.

Ex:
<select>
<option value=1>Eggs</option>
<option value=2>Cheese</option>
<option value=3>Milk</option>
</select>

In my case, i need to pass the value(money) each one costs. The solution i have found is to use de data-* attribute, but i dont know if this approach has issues.

Ex:
<select>
<option value=1 data-cost='5.20'>Eggs</option>
<option value=2 data-cost='2.40'>Cheese</option>
<option value=3 data-cost='1.73'>Milk</option>
</select>

Remember that this is just one of many selects dinamically generated at the server side and sent via AJAX to JS.

Thanks!

@Daniel,

Yeah, you probably can't use this for OPTION elements. But, using the HTML5-friendly "data-" attribute, you should be good. You could also look into the metaData jQuery plugin which allows you to use CSS as well as other attributes to store meta data.

Thanks for this post, it gave me a clean solution for some pages where the JSON payload for a JavaScript grid was being put into a hidden textarea (and the resulting problems):
http://tech.agilitynerd.com/embedding-json-within-generated-html

Thanks again.

@Steve,

Very cool my man. As I said on your blog, I've been using and loving the use of Script tags for all kinds of data containers.

@Aaron,

it's not jQuery specific at all.

Post A Comment

Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.

Please review the following issues:

Author Name:
Author Email:
Author Website:
Comment:	Supported HTML tags for formatting: <strong>bold</strong>   <em>italic</em>   <code>code</code>
	Remember my information
	Subscribe to comments
	Send me a copy of this comment