----- Original Message -----
From: "Mike Williams" <[EMAIL PROTECTED]>
All that said: if you can think of a way to do it purely client-side
with JavaScript, that'd be fantastic!
--
Hi Mike
Well, yes and no...
setTimeout (and in some ways setInterval) provide a poor mans version of
threading. I use them for this in lengthy operations where I want to get
control back to sequential code "quicker". Some points:
1 - I saw a test page somewhere (sorry, it was some time ago, cant recall a
URL) that showed pretty bad behaviour regarding timing in firefox. IE was
pretty much ok.
2 - Access to/accessing the DOM via setTimeout gives "odd" results when
comparing IE/FF (I suspect also for other browsers too). In essence, some
dom operations give you, in effect, no threading at all. In which case, you
might as well not have bothered. Perhaps a given browser "blocks"
timer/threads while one thread is doing certain things in the tree.
Dunno... but that's how it seems.
3 - Given 2, use for testing some other kind of operation (looped), perhaps
accessing the OS/disk, writing to a file, or whatever. Let it run while you
"do stuff" on the page - prove you are getting thread-like behaviour in real
time.
4 - While working on this kind of thing, don't use a debugger. Don't even
have one attached to your process.
5 - I suspect, but don't know, that only grief will await you. With the
number of browsers needed to be supported, I can't imagine that you'll get
anything like a robust implementation using setTimeout. But, I could be
wrong...
Aside:
I do wonder, however, why a javascript array of (say) UserTestObjects could
not be "read" just the same as an HTML table. Am I missing something?
function UTO(sCommand, sTarget, sValue)
{
this.command = sCommand;
this.target = sTarget;
this.value = sValue;
return this;
}
Now all the test runner wants is an array of these... surely?
Russ
_______________________________________________
Selenium-users mailing list
[email protected]
http://lists.public.thoughtworks.org/mailman/listinfo/selenium-users
