Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #7560
| Path | csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail |
|---|---|
| From | Seni Seven <OneWhoLovesYou@humanitarian.ca.invalid> |
| Newsgroups | comp.lang.javascript |
| Subject | Re: Parsing String of Named Function & Converting To Source |
| Date | Wed, 19 Oct 2011 08:01:11 +0000 (UTC) |
| Organization | A noiseless patient Spider |
| Lines | 141 |
| Message-ID | <Xns9F83701848613SSca@88.198.244.100> (permalink) |
| References | <Xns9F82AB08718BBSSca@88.198.244.100> <8voi2r92.fsf@gmail.com> |
| Injection-Date | Wed, 19 Oct 2011 08:01:11 +0000 (UTC) |
| Injection-Info | mx04.eternal-september.org; posting-host="Cakr3kkvUKzaM/pEqGssyQ"; logging-data="26251"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+e75Fju837nLG9gc8oECCbUUTGfS44rp4=" |
| User-Agent | Xnews/5.04.25 |
| Cancel-Lock | sha1:oi8r4+lzvRl6DjCMBbEbyWZ+aSI= |
| Xref | x330-a1.tempe.blueboxinc.net comp.lang.javascript:7560 |
Show key headers only | View raw
Lasse Reichstein Nielsen <lrn.unread@gmail.com> wrote on Tue 18 Oct 2011
07:34:17p
> Seni Seven <OneWhoLovesYou@humanitarian.ca.invalid> writes:
>
>> Suppose I have HTML markup with a SCRIPT element as shown below:
>>
>> <script type="text/javascript">
>> function multiply(a, b) {
>> return a * b;
>> }
>> var i = multiply(2, 5);
>> document.write("The value of <i>i</i> is " + i);
>
> Invalid HTML 4 markup. You should escape the </ inside the string.
Yes, my parser actually stopped on the "</i>" etago markup, of all things.
And yes, the HTML 4.1 recommendation specifies this is invalid.
Then I read one article (I believe there are others) on this subject of
CDATA content inside a SCRIPT element which first asserted that (1) it was
nonsense to have this in the recommendation and (2) that no browser
implementation actually followed this part of the recommendation: that is,
all textual content between the start and end tag of a SCRIPT element was
not effectively regarded as part of HTML markup, so I made my parser ignore
all content between the start and end tag of a SCRIPT element and process it
as script code.
But even so, I admit that I should backlash the string pattern "</"
appropriately to be in compliance with the recommendation.
>
>> </script>
>>
>> All of this markup and contained script code is retrieved as a string
>> using Ajax.
>
> So, it's a string with the above content (newlines and all).
Ajax effectively recovers data that become strings if handled by
ECMAscript/Javascript, doesn't it?
>> I have an HTML parser with support for parsing the string containing
>> the script code.
>
> Ok.
>
>> In parsing the contained code (using JavaScript, of course), how would
>> you convert the contained script code from string into source?
>
> What's the difference? I assume your HTML parser extracts the content
> of the script element as a string.
> What do you want to do with that string?
Well, normally, all script as either elements in HTML documents or loaded
from external JS files get processed during HTML document loading in the
browser. This is before the document.close() call has effectively been
invoked and completed, right?
But what do you do if you bring in ECMAscript code (as strings via Ajax)
AFTER the document.close() call has been made? You want to make function
definitions (named functions) part of the executable code in the HTML
document (object?), just as if it were made during document loading. As for
script code outside of named function definition scope, you want to parse
and execute immediately, in order of retrieval via Ajax.
>> What I have found so far (using Firebug in Firefox for development) is
>> this:
>>
>> 1) Isolating the string "function multiply(a, b) { return a * b; }" and
>> then passing that string as an argument to eval() does not cause the
>> definition of the function named "multiply," it seems.
>
> It probably does, but in the scope where the eval is executed, not at
> the global scope.
> For that, you can use, e.g.,
> window.eval(sourceString);
> (or any other non-direct call to eval).
Okay.
>> 2) I can parse the function definition in a way to create the string:
>>
>> "var multiply = new Function (\"a\", \"b\", \"{ return a * b; }\");"
>
> How wasteful :) The function syntax is perfectly fine, no need to make
> it more convoluted.
>
>> and then use eval() on it (without error). And then when I eval() the
>> global level code in a debugger (Firebug in FireFox), as so
>>
>> eval("var i = multiply(2, 5); document.write(\"The value " +
>> "of <i>i</i> is \" + i);"); // parsed code as string on one line
>>
>>
>> the value of identifier 'i' is immediately set to 10 in the debugger,
>> but the debugger exits with error 'multiply is not defined', which
>> indicates multiple levels of execution contexts, I suppose. In fact,
>> if I just do an eval() on the "multiply" assignment of the Function
>> constructor, the identifier 'multiply' is still not defined.
>>
>> QUESTION: What's the solution to the goal I want to achieve?
>
> Try:
> var script = document.createElement("script");
> script.textContent = sourceString;
> document.body.appendChild(script);
> This executes the code as top-level, non-eval code (which there is no
> way to do in pure Javascript).
> No guarantees wrt. old browsers, but it seems to work in the current
> versions.
Yes, tried, and found it works.
> Alternatively, just use a non-direct call to eval.
> var topLevelEval = eval;
> topLevelEval(sourceString);
Yes, tried, and found it works.
I am looking at search results (http://is.gd/jwhNln) to understand why
indirect calls to eval() work.
>
>> The string representing the markup obtained by Ajax retrieval is then
>> passed to a parsing function which is supposed to do it all: parses
>> the HTML markup using DOM methods to insert the DocumentFragment into
>> the main document tree. It also parses CSS (stylesheets and style
>> attributes), as well as any Javascript contained inside SCRIPT
>> elements. Everything becomes part of the interactive document by using
>> DOM method calls, HTML --> element
> Why not pass it as something easier to parse and separate into
> CSS/HTML/JS, e.g., JSON?
I will look into this most certainly and try to make it workable.
The suggestion by poster "Andreas Bergmaier" to use iframes probably is
worthy of exploring. Perhaps I made this overly complicated.
Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar
Parsing String of Named Function & Converting To Source Seni Seven <OneWhoLovesYou@humanitarian.ca.invalid> - 2011-10-18 13:48 +0000
Re: Parsing String of Named Function & Converting To Source Andreas Bergmaier <andber93@web.de> - 2011-10-18 16:03 +0200
Re: Parsing String of Named Function & Converting To Source Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-18 19:29 +0200
Re: Parsing String of Named Function & Converting To Source Lasse Reichstein Nielsen <lrn.unread@gmail.com> - 2011-10-18 18:34 +0200
Re: Parsing String of Named Function & Converting To Source Seni Seven <OneWhoLovesYou@humanitarian.ca.invalid> - 2011-10-19 08:01 +0000
Re: Parsing String of Named Function & Converting To Source Dr J R Stockton <reply1142@merlyn.demon.co.uk> - 2011-10-19 20:09 +0100
csiph-web