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 do if (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
