now you can easily get x.fn() // 54

this was testes on ie7

If the script has an error when it runs, then execScript() catches the exception, and it creates a *new* exception: “Could not complete the operation due to error 80020101″. You lose all information about the original error…

If you get 80020101 on a client’s machine you have *no* information about the error – and it will be a bitch to diagnose (google 80020101 – lots of problems and incorrect answers). [PS: If you are reading this because you have got that error, then try replacing "execScript(code);" with "(window.eval || eval)(code, null);" !]

To see the error, try the following in the address bar IE6 (without a debugger installed – your clients don’t have one!): javascript:execScript(‘syntaxerror;’);

Calling eval(code, null); is the way to go for non-IE browsers, because the second parameter is the context and null means use global as the context.

Ryan Moore:
You had a link to window.eval and eval
which says window.eval is evil – however the evilness is easily avoided by writing a global function which:
a) has *no* local variables (e.g. only does eval and returns) and
b) is not declared inside another function (is *not* a closure – doesn’t capture variables of the outer function/s.
c) calls window.eval or eval appropriately

Sebastian Werner:
(new Function(code))() is not the same. If the code contains any var statements at top level, then declared variables should end up in the scope of the function, not at global scope e.g.
javascript:(new Function(‘var xxx=5′))(); alert(window.xxx);
alerts undefined in IE6 (hmmmm – alerts 5 in FF) versus:
window.eval(‘var xxx=5′); alert(window.xxx);
alerts 5.

lou:
try { window.execScript(code); } catch (e) {}
try { eval(code); } catch (e) {}
That will run the code twice on IE – not what you want at all.

How about:
try { window.execScript(code); } catch (e) {}
try { eval(code); } catch (e) {}

i think it iwould be better to use a textarea then apply the source formatting behind it.

tb.element.show( ‘bodyDiv’ , ‘application’, ‘index_body’ );

The twobirds system documentation will be about 1 page for each “core” and “framework”. There is nothing more required to fully explain the system.

If you want to contact me, my eMail is frank dot thuerigen -at- phpbuero justAnotherDot de. Please add “ajaxian” to the topic line so I know where it comes from – I get a lot of spam in english language and I´d like to see the comments, not find them after a year in the spam bin ;-)

Have fun!

Look at the following code snippet, it will explain everything:

application.index_body = {

init: function (pDivId) {
tb.element.require(
“[ [ 'css', 'application', 'index_body' ], ” +
” [ 'tpl', 'application', 'index_body' ], ” +
” [ 'js', 'tb', 'effect.fadeTo' ] ]”,
‘application.index_body.display( “‘ + pDivId + ‘” )’ ,
true
);
},

display: function (pDivId) {
var myHtml = tb.loader.tplget(‘application’,'index_body’);
tb.div.replace( pDivId, myHtml );
tb.element.require(
“[ [ 'js', 'application', 'menu' ], ” +
” [ 'css', 'application', 'menu' ], ” +
” [ 'tpl', 'application', 'menu' ], ” +
” [ 'js', 'application', 'user_greeting' ], ” +
” [ 'css', 'application', 'user_greeting' ], ” +
” [ 'tpl', 'application', 'user_greeting' ], ” +
” [ 'js', 'application', 'submenu' ], ” +
” [ 'css', 'application', 'submenu' ], ” +
” [ 'tpl', 'application', 'submenu' ], ” +
” [ 'js', 'application', 'window' ], ” +
” [ 'css', 'application', 'window' ], ” +
” [ 'tpl', 'application', 'window' ] ]”
);

tb.element.show( ‘toprightcontainer’ , ‘application’, ‘user_login’ );
}

};

This is productive code. I was working on that special problem for more than 1 year, now it works on every browser thats halfway modern. This is only a fraction of the libs abilities. I can recursively load objects consisting of css,tpl and js object code files, it all works asynchronous and executes out-of-order. In my opinion this allows unlimited complexity while having managable code.

twoBirds V2.0 has just been declared stable, it works easily with other libs. And it is open source.

Im working on my HP now to make a download and documentation area (had no time for that so far), but the libs are pretty self-explaining just in case you want to rip the code from the prototype. The window management system is NOT OPEN SOURCE though. And it is a work in progress, permanent beta.

Cheers from Germany, Frankie.

b.html
———————-
<script language=’javascript’>
function loadTest()
{
window.parent.eval(“function test(){return ‘success’;}”)
}
</script>
<input type=’button’ value=’Load’ onclick=’loadTest()’>

//HIDDEN IFRAME.


b.html
—————————

//Can make it an HIDDEN IFRAME.

b.html
——————————-

function loadTest()
{
window.parent.eval(“function test(){return ‘success’;}”)
}

After loading a.html, click on “Test” button it doesn’t work, now click on Load in the iframe and then click on “Test”. Hurray it works :-). Tested on IE6 and FF2

http://www.codeproject.com/Ajax/AjaxMDIWeb.asp

I’ve noticed that the sample works like a charm in IE, but that it degrades in Firefox because of its exclusive use of execScript. I’ve tried replacing it with window.eval() and surprisingly, that works in IE as well; but not firefox. eval.call() doesn’t work either. And this leads me to believe that in FF, I’m not get a proper reference to the win object?

Tried everything to get this sample to work in FF, but have had no luck. A real brick wall. I’d truly appreciate any ideas you might have.

But it seems that: function outer(){ function inner(){}; }
is handled like: function outer(){ var inner = inner(){}; }
but not as: function outer(){ inner = inner(){}; }

The last way exposes inner to the world.

You can see this in the jsolait-library and you can test it with an example found in http://planet.openjsan.org/

function loadMyFuncModule() {
// imagine this was loaded via XHR/etc
var code = ‘function myFunc() { alert(\”myFunc\”); }’;
return eval(code); // doesn’t work in FF or IE
}

function runApp() {
loadMyFuncModule(); // load extra code “on demand”
myFunc(); // execute newly loaded code
}

myFunc (); // produces an error

With a little change it works:

loadMyFuncModule = function() {
// imagine this was loaded via XHR/etc
var code = ‘myFunc = function() { alert(\”myFunc\”); }’;
return eval(code); // d o e s work in FF and IE
}

runApp = function() {
loadMyFuncModule(); // load extra code “on demand”
myFunc(); // execute newly loaded code
}

runApp()

Any HTML “module” that gets pulled in via XHR can run its own JavaScript. The script executes in the global namespace, but won’t pollute it.

It’s ugly, but it works.

globalEval(foo);
bar(); // defined in the just eval’d code

This will work in IE, but it will not work in other browsers, as the timeout will not be triggered until the current script block finishes.