Alessandro Sala schrieb:
> 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?
Mhh, just one question. Is it possible to use only one script element?
e.g. switch the source after each load? That would be interesting to
make it perform a little better.
In general I think it is completely OK to use document.write in Internet
Explorer as long as the browser supports this. Maybe after some years it
really supports XHTML. It is also OK to switch afterwards I think. So I
would say:
1. document.createElement & appendChild => Gecko, Opera, Safari, etc.
2. document.write => IE
I have my problems to understand why document.write(manyscriptags) work,
but document.getElementsById("head")[0].innerHTML += manyscripttags not.
Are you sure you also has the problems regarding code evaluation in this
case?
There are also plans to improve the demo section even more. Maybe we
find another solution in some month, but for now this is completely OK.
Sebastian
>
> 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
-------------------------------------------------------------------------
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
