[jira] Commented: (TRINIDAD-1149) ApacheChart.js resource loading problems

["Andy Schwartz (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/TRINIDAD-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611822#action_12611822 ] 

Andy Schwartz commented on TRINIDAD-1149:
-----------------------------------------

The patch solves the problem by mapping paths of the form "jsLibs/Debug" to "jsLibsDebug/" in CoreClassLoaderResourceLoader.  And alternative approach would be to tweak the paths generated by LibraryScriptlet to match the paths expected by CoreClassLoaderResourceLoader.  I decided not to go that route, since CoreClassLoaderResourceLoader is not the only consumer of LibraryScriptlet paths, which means that tweaking LibraryScriptlet would have ripple effects that need to be handled.

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