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. 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
