How to parse text as JavaScript?

Question

This question of mine (currently unanswered), drove me toward finding a better solution to what I'm attempting.

My requirements:

• Chunks of code which can be arbitrarily added into a document, without an id:

<div class="thing">
  <elements... />
</div>

• The objects are scanned for and found by an external script:

var things = yd.getElementsBy(function(el){
    return yd.hasClass('thing');
},null,document );

• The objects must be individually configurable, what I have currently is identifier-based:

<div class="thing" id="thing0">
    <elements... />
    <script type="text/javascript">
      new Thing().init({ id:'thing0'; });
    </script>
</div>

• So I need to ditch the identifier (id="thing0") so there are no duplicates when more than one chunk of the same code is added to a page

• I still need to be able to config these objects individually, without an identifier

---

SO! All of that said, I wondered about creating a dynamic global variable within the script block of each added chunk of code, within its script tag. As each 'thing' is found, I figure it would be legit to grab the innerHTML of the script tag and somehow convert that text into a useable JS object.

Discuss.

Ok, don't discuss if you like, but if you get the drift then feel free to correct my wayward thinking or provide a better solution - please!

d

Paraphernalia

Answer 1

I kind of understand where you are coming from and the only advice I can give you on this is to look into the eval() tag. The eval() function evaluates and/or executes a string of JavaScript code. First, eval() determines if the argument is a valid string, then eval() parses the string looking for JavaScript code. If it finds any JavaScript code, it will be executed.

So you could parse the text inside of a DIV or any element by using the eval() tag. Sorry I couldn't help you further.

Madi

Ok, this is a step closer I think - I'd forgotten about eval(). Is eval() considered bad practice? I've heard various things, the idea of executing any string as javascript, via a method call sounds sketchy... – Paraphernalia

To be honest eval() is more resource intensive than it is a security risk (at least in JavaScript), unless you're passing user information. Eval() is considered more dangerous in languages like PHP for example than JS. Here are some caveats of using eval() in Javascript: 1. Improper use of eval opens up your code for injection attacks 2. Debugging can be more challenging (no line numbers, etc.) 3. Eval'd code executes more slowly (no opportunity to compile/cache eval'd code) 4. Each invocation of eval() creates a new instance of the JavaScript interpreter. This can be a resource hog. – Madi

Thanks Dwayne, yeah I'm in agreement about eval() now - did some reading around the risks/benefits. In my case there is almost zero risk and the problem it solves for me has a large pay-off. Also in my case, eval() might only ever be run once per appropriate element found, and that might only ever be up to 5 elements on a page, so 5 evals. If I'm wrong in thinking this isn't a performance hit.... please correct me :P – Paraphernalia

The degradation of performance would probably not even be noticeable unless you're profiling your Javascript with Firebug or something, if anything it might add a few extra milliseconds. I'd say you are safe with 5 eval's, provided you're not executing large chunks of Javascript for per eval(). – Madi

Answer 2

Why not

<div class="thing virgin">
  <script>
    var newElems = yd.getElementsBy(function(el){
     return yd.hasClass(el,'thing') && yd.hasClass(el, 'virgin');
    },null,document );
    // find the 'virgin's and remove the 'virgin' class from them as you init?
  <script>
</div>

You could of course remove the <script> tag entirely if you are adding this element via javascript, and just execute the code on the elements you create.

Codd

Not sure this is going to benefit me more than what I'm currently doing. As it stands, I do currently have everything being executed in an external file, but that file gets loaded on potentially hundreds of pages - so it is a common file. I definately won't have the same config requirements from <div class="thing"> #1 and <div class="thing"> #69, between pages 1 and 200 - if you catch my meaning. So far I can either define config objects in a 'bank' of info, identified by an instantiated Thing() object by the URL of the page it resides within, or do the config within a script block as above :/ – Paraphernalia