Hello Sebastian,
It seems I was too hasty. I made further testing and it appears that the
XMLHttpRequest workaround for IE isn't reliable too: reloading the
application
several times in a row, sometimes it fails with the same errors as
without XMLHttpRequest.
That's bad. Mhh. Another (working) solution would be great.
I fear we will need to keep document.write() for IE for some time yet.
Maybe we could generate just an array and support different loading
implementation then. Currently it's a bit hard-coded to use
document.write. We could generate an array and then just use one of
the loading methods, also written to the qx.js. What do you think?
I completely agree. Actually, in my own "development" version of
generator.py, I switched to this approach from the beginning: an array
holds the script paths and a function selects the working implementation
according to the browser it is running in and iterates over the array
loading the scripts.
In the meantime, I kept crashing my head against the script loading bug
in IE 6, and finally found a (somewhat convoluted) way to guarantee the
load order of scripts when they are inserted using createElement() and
appendChild(): rethinking to David Perez's suggestion about making the
end of one script stat the loading of the following one, I found IE
provides a rather obscure feature (at least for me up to now!): script
elements have an onreadystatechange event handler and readyState
property, similar to XMLHttpRequest.
When the includer creates the first script element, it sets its
onreadystatechange attribute to a function which, when the loading is
completed, creates the second script element and so on until all scripts
are loaded (you can see a sample implementation of this technique at
http://www.alessandro.sala.mclink.net/inctest/ as usual).
While this should work for loading qooxdoo classes in the correct order,
the script code in the body of the document still gets parsed before all
scripts are loaded, so the problem is only half-solved (I wish
_javascript_ had a way to suspend the excution, waiting for an event, but
unfortunately we don't live in the best of possible worlds :-) [sorry
for the philosophical off-topic!]): then we should also change the way
the application is initialized, for example by wrapping the
initialization code into a function which will be called by the includer
script when all classes are finished loading;
All in all, I'm not sure it is worth all this effort to only support a
single buggy browser (albeit a very widely used one) also because, from
what I read, IE7 still doesn't really support XHTML (anyone has already
tried it?), so if the container document takes full advantage of XHTML,
then you cannot use it in IE anyway, while if document is
HTML-compatible XHTML then document.write() is still available when
running inside IE. Not to mention that the problem is limited to the
"development" version of applications.
There is critical point, however: if/when Internet Explorer will fully
support XHTML documents, if the load order bug will still be there even
with the XHTML DOM, then we will probably be forced to modify the way
applications are initialized (o we will need to switch to preprocessing
the header file): and if this has to be done, the sooner is better.
It would be very interesting if someone who is already using IE7 could
try my test page, particularly the DOM-pre and DOM-post links, and see
if the load order bug has been fixed.
I've tried you page(DOM-post and DOM-pre links) and there are some
errors(according to your output) while keeping clicking on the links
several times. :-(
If it is, then we can definitely
stick to document.write() for IE6 without further concerns.
Do you agree?
Cheers,
Alessandro
|
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
