Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.0.8-core, 1.2.8-core
-
None
Description
As part of the fix for the following bug:
TRINIDAD-1083 Chart component does not render anymore in 1.1 and 1.2 trunk
We introduced the ApacheChart.js code into the Trinidad "common" JavaScript library. This resulted in two new problems:
1. The size of the common library increased by 122K (when using obfuscated JS, more when using debug JS).
2. When running with DEBUG_JAVASCRIPT set to "false", the ApacheChart.js code is actually loaded two times - once with the common library, and a second time when the ApacheChart.js is requested separately.
As a result, when running in non-JS-debug mode, we now load an extra 244K of JS code on every page. This is unacceptable, since it negatively impacts performance of all Trinidad pages/applications, even those which do not use the chart component.
There is a third problem which existed before the fix for TRINIDAD-1083, and still exists today:
3. When running with DEBUG_JAVASCRIPT set to "true", the direct request for the debug version of the ApacheChart.js library fails with a 404 error.
Looking back at TRINIDAD-1083, the correct fix would have been to address issue #3 - ie. to make sure that our resource loader actually successfully handles the request for the debug version of the ApacheChart.js library.
After some debugging, I was able to figure out why this request was failing. The following comment from my soon to be submitted patch explains:
// LibraryScriptlet prefixes debug JS libraries with the prefix
// "Debug". So, for example, the "Foo.js" library ends up being
// referred to via an URL of the form "<base>/jsLibs/DebugFoo.js".
// Unfortunately, this is out of sync with reality, since our
// JS libraries actually live under a "jsLibsDebug" directory,
// ie. the debug "Foo.js" lives at "META-INF/adf/jsLibsDebug/Foo.js".
// As a result, CoreClassLoaderResourceLoader fails to locate
// scripts that are rendered via a LibraryScriptlet.
//
// To work around this problem, this code converts paths of the
// form "jsLibs/Debug" to "jsLibsDebug/", which allows our
// library look ups to succeed.
Unforunately, I haven't been able to figure out when this problem was originally introduced, or how this was actually working in the past.