On Wed, 19 Nov 2014 16:10:53 -0200, Paul Stanton <pa...@mapshed.com.au>
wrote:
Thiago,
Tapestry is smart enough to not download JS twice.
I'm not sure you understood my example. It may not download the same JS
code twice in the same page, but, considering different pages in the same
site, the user browser would download the same JS code twice or more.
Example: x.js and an S stack. PageA includes x.js. PageB includes S.
x.js's contents is downloaded twice, beating the whole idea of a stack, JS
aggregation and caching. And don't forget that one stack can include other
stacks.
I think this logic is flawed, or at least could be optional, certainly
documented!
I disagree! :) It couldn't be made optional, I think, without creating a
lot of confusion.
Putting scripts within a stack is the only way to have them aggregated
(since 5.2?). This aggregation can yield considerable performance
improvements in the right kind of app. For example, we have roughly 3
complex and heavily used pages which use around 30 shared components, up
to 20 on each page.
So why doesn't your PageA above use the S stack in the example instead of
just including x.js? Caching included, in the end, less bytes will be
downloaded and processed by the browser.
its like an opposite of the Java import paradigm - ClassA imports
StringUtils and EJBContainer. ClassB imports StringUtils. Therefore
ClassB must also import EJBContainer ?? no...
I think this metaphor isn't valid at all, because of the huge difference
in how the importing is done.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
