You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Hudson (JIRA)" <ji...@apache.org> on 2010/09/25 02:42:34 UTC

[jira] Commented: (TAP5-1279) Importing a JavaScript library that is part of a stack should import the entire stack instead of the individual library (to take advantage of JavaScript aggregation)

    [ https://issues.apache.org/jira/browse/TAP5-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914725#action_12914725 ] 

Hudson commented on TAP5-1279:
------------------------------

Integrated in tapestry-5.2-freestyle #197 (See [https://hudson.apache.org/hudson/job/tapestry-5.2-freestyle/197/])
    TAP5-1279: Importing a JavaScript library that is part of a stack should import the entire stack instead of the individual library (to take advantage of JavaScript aggregation)


> Importing a JavaScript library that is part of a stack should import the entire stack instead of the individual library (to take advantage of JavaScript aggregation)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-1279
>                 URL: https://issues.apache.org/jira/browse/TAP5-1279
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.2.0, 5.2.1
>            Reporter: Andy Blower
>            Assignee: Howard M. Lewis Ship
>             Fix For: 5.2.1
>
>
> The stack mechanism doesn't seem to be removing duplicate javascript references as I expect it to. Tapestry JS has always worked on a component requesting the JS assets it needs and then Tapestry ensured that each required JS asset was added to the page once and only once, even if several components asked for the same JS asset. The stack system doesn't seem to follow this model...
> For example, say I have a component "Comp" that specifies it needs the "CompJS" asset, and is used on pages "Page1" and "Page2". If Page1 doesn't have much more to it and only needs CompJS then that's what should be included by Tapestry, since Comp @Import's CompJS. All well and good.
> Now, if Page2 has a lot of other components with their own JS files which are then combined into a T5 stack and requested by the page's @Import then I would not expect CompJS to be referenced on the page since it's already included in the stack file. It seems to be in T5.2.0 with my testing.
> Unless I'm mistaken about how this is working, then I fail to see how this stack mechanism provides much benefit over simply putting all my projects' JS into a single file and referencing that in each page. The only advantage is to split it up into easily editable chunks, I still have to manage the aggregation. I think it's going to be very easy to get duplicate JS in the rendered html page with this system.
> If a stack is imported which contains CompJS, and another component imports CompJS individually, just output the reference to the stack, and not CompJS. 
> There are two ways to implement the remaining behaviour:
> 1) If the stack is not imported, and a component imports CompJS individually, just output the reference to CompJS.
> 2) If the stack is not imported, and a component imports CompJS individually, output a reference to the stack containing CompJS. This is more difficult and may be tricky if the component has been defined as being part of more than one stack.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.