Yes +1 for that, I will work on the issue later this year again, my
guess is we probably can enable it via a chain and event listener system
and header manipulation, but I have more important work pending, but I
want a solution which enables debugging for all users for 2.0.1. So if
we go that route it is fine with me.
The funny thing is that other libraries are using the dynamic loading
via header manipulation and fail on chrome, so I guess through testing
of that method was not really first priority by them.
(I will file a bugreport for them next week)
Werner
Am 25.06.10 22:39, schrieb Leonardo Uribe:
Hi Werner
I think we should activate it with a web config param. Debug using the
real scripts in firefox is really useful. The idea could be provide a
jsf-uncompressed.js file with all scripts as default on dev mode, but
have a config param like
org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS by
default false.
regards,
Leonardo
2010/6/25 Werner Punz <[email protected] <mailto:[email protected]>>
Hello
I have been doing some performance tuning for the last day on our
jsf.js scripts. So far things look good, the performance seems to be
slightly faster (about 5-15% on a modern browser) than Mojarras
under my testing conditions, except for one area.
jsf-uncompressed.js does not work out as it should.
Here is a small description: We use jsf-uncompressed.js to load the
other scripts dynamically in dev mode.
This works except for some things.
To load the scripts and have them displayed properly in the debugger
the loading must be done over appended script elements in the head,
to load them and have them run, a script load via xhr and eval
afterwards suffices.
The problem now with the head method is, it fails in slight details
on many browsers, especially if the scripts become bigger. In
Chrome, you cannot rely on the loading order that way (known issue
since 2008)
In IE I have similar sideefects. What I would propose is following.
Since a normal include works (and script loading afterwards happens
over the reliable but not debuggble load - eval method)
It might be possible to work it out over chains which trigger the
next load upon an event finish, but for now this is overkill.
I ran tests with the script src method over Firefox, IE in all its
recent incarnations and Chrome based browsers and only on Firefox it
ran reliably.
We go back to step one as Leonardo proposed and have the build
process bundeling all our files into one big jsf-uncompressed js file.
I think for 2.0.1 this is the best solution.
The scripts themselves if they encounter a src= tag are not affected
since I fall back on the reliable method of synchronised xhr get
with added eval for that part.
I sure will revisit that part later this year, but for now having
one big uncompressed file should be ok to keep the users happy.
I think there are other issues more important, to tackle, than a non
specced dynamic loading mechanism which keeps the files apart.
Werner
