[
https://issues.apache.org/jira/browse/TRINIDAD-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf updated TRINIDAD-1149:
-----------------------------------------
Resolution: Fixed
Fix Version/s: 1.2.9-core
1.0.9-core
Status: Resolved (was: Patch Available)
Thanks to Andy Schwartz for his patch.
> 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.0.8-core, 1.2.8-core
> Reporter: Andy Schwartz
> Assignee: Matthias Weßendorf
> Fix For: 1.0.9-core, 1.2.9-core
>
> Attachments: TRINIDAD-1149-trunk-1_2_x.patch
>
>
> 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.
