[
https://issues.apache.org/jira/browse/TRINIDAD-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018964#comment-13018964
]
Scott O'Bryan commented on TRINIDAD-1910:
-----------------------------------------
Yes. This is a stop gap and, IMO, the wrong solution. The correct solution
would be to actually fix TRINIDAD-53. The Javascript obfuscator could be
modified to produce a set of "tokenized" JS libraries that contain something
like ${NAMESPACE} inside of them and then, before they are sent to the browser,
the ${NAMESPACE} token can be replaced with the portlet namespace. This will
mean you have multiple copies of the JS, but it would have version isolation.
> portal: common.js is included serveral times
> --------------------------------------------
>
> Key: TRINIDAD-1910
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1910
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Portlet
> Affects Versions: 1.0.10-core
> Reporter: Daniel Niklas
> Attachments: Page.js-trinidad-1910-patch.txt, XhtmlUtils-patch.txt
>
>
> The commons.js is included several times, when you have more than one
> trinidad-porlet on your portal-site.
> In XhtmlUtils#writeLibImport there is a mechanism to prevent including
> javascript libs more than one time (portal environment). This mechanism is
> not working, when you have more than one Trinidad-portlets within different
> web apps.
> The problem is, that the key contains the webapp context!
> Here " _uixJSL" for example contains:
> "/webapp-one/adf/jsLibs/Common1_0_10.js"
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
