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