ApacheChart.js resource loading problems
----------------------------------------
Key: TRINIDAD-1149
URL: https://issues.apache.org/jira/browse/TRINIDAD-1149
Project: MyFaces Trinidad
Issue Type: Bug
Components: Archetype
Affects Versions: 1.2.8-core, 1.0.8-core
Reporter: Andy Schwartz
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
