Wow this is good news. I've been mucking up env.js for awhile now locally
and was afraid I wouldn't see it go where I hope it will.
John you mentioned the other platforms you want it to be used on and I think
this would be ideal. One thing that is currently preventing that is that
the basic window code, which essentially emulates the browsers behavior and
provides the standard global functions and objects available in browsers, is
mixed with Java specific code. If env.js has these provided by the
container, eg rhino jar + 'implementation of xmlhttprequest jar', then
env.js could stay generic across all the implementations. It's a little
more work but inverts the control so env.js could be used by
javascript/spidermonkey to emulate the browser as well. This doesnt really
help perl/python but might keep the patterns clearer.
So I guess what I'm asking is, for the javascript 'env.js' is it worth it to
abstract so the same script could be used across javascript engines? A
simple way to achieve this is to use 'providers' which are just aliases to
implementations:
- in env.js -
window.XMLHttpRequest = Env.XMLHttpRequest;
- in rhino.env.js -
Rhino = {
XMLHttpRequest = function()...
};
EnvProvider.XMLHttpRequest = RhinoEnv.XMLHttpRequest;
allows you to include a second script, say 'rhino.env.js' , to keep env.js
reusable in spidermonkey?
Thatcher
On Thu, Jun 26, 2008 at 11:00 AM, fuzziman [EMAIL PROTECTED] wrote:
So excited to see that you are actively working on this John! :-)
I can see you've been concentrating on document parsing behavior, while
I've
just been looking at automated testing in rhino. From my testing
perspective, I made a couple of patches:
- in test(), wrapping fn() and the next lines in try/catch/fail, so tests
don't fail silently but get logged
- as part of testrunner's results() method, quit with error code if there
was a failure, so ant build can stop if a failure occurred.
I also patched another bug (I'm not sure whether you experience this bug
too..)
$.get callback wasn't being called.
I tracked it down to the setInterval/clearInterval code.
2 problems:
- the very first setInterval returns 0, which evaluates to false in jquery,
and so timer will never be stopped, because in jquery you doif (ival)
- as soon as stop() is called, the entire rhino engine stops! not sure
why. stop() is deprecated anyway. easy workaround though, I changed it
to use the standard java runnable stop pattern of checking a local variable
and returning:
//--
// Timers
var timers = [{}];
window.setTimeout = function(fn, time){
var num;
return num = setInterval(function(){
fn();
clearInterval(num);
}, time);
};
window.setInterval = function(fn, time){
var num = timers.length;
var isRunning = true;
var timerObj = {
thread: new java.lang.Thread(new
java.lang.Runnable({
run: function(){
while (isRunning){
java.lang.Thread.currentThread().sleep(time);
fn();
}
}
})),
stop: function() {isRunning = false;}
};
timers[num] = timerObj;
timers[num].thread.start();
return num;
};
window.clearInterval = function(num){
if ( timers[num] ) {
timers[num].stop();
delete timers[num];
}
};
//--
If you like, I can keep posting my findings on this thread as I find them.
Once again, good to see you working on env.js, its amazing!
Keep up the good work John!
John Resig wrote:
I'm working on this (well, trying to get more of the jQuery test suite
to pass). I've broken it out into a separate project here:
http://github.com/jeresig/env-js/tree/master
--
View this message in context:
http://www.nabble.com/jQuery-test-suite-and-jsUnit-compatibility-tp15882865s27240p18136064.html
Sent from the jQuery General Discussion mailing list archive at Nabble.com.
--
Christopher Thatcher
