True, visiting PageA and PageB if they both had their own stacks would
download shared snippets twice. The trade off between more bytes *IF*
the user visits both PageA and PageB or a single resource if they just
visit PageA.
In my example, the 3 large pages have 3 distinct audiences. Only select
people would visit all 3. Therefore it would be great to be able to
combine all scripts for each of these.
I'm not sure which is a better approach generally, but I think the
feature of combining scripts is wasted on the current approach.
On 20/11/2014 6:57 AM, Thiago H de Paula Figueiredo wrote:
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
