[jira] Created: (TAP5-1279) The stack model for JavaScript combination doesn't de-duplicate individual references

2010-09-21 Thread Andy Blower (JIRA)
The stack model for JavaScript combination doesn't de-duplicate individual 
references
-

 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


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.



[jira] Commented: (TAP5-1279) The stack model for JavaScript combination doesn't de-duplicate individual references

2010-09-21 Thread Andy Blower (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12912886#action_12912886
 ] 

Andy Blower commented on TAP5-1279:
---

Follow up to TAP5-769

 The stack model for JavaScript combination doesn't de-duplicate individual 
 references
 -

 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

 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.