Thiago,
Tapestry is smart enough to not download JS twice. Your 2nd paragraph
sounds more likely - someone took the approach that if a resource is in
a stack, then that resource must require the whole stack.
I think this logic is flawed, or at least could be optional, certainly
documented!
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.
In development mode it makes sense to @Import js/css relevant to each
component, however once stabilised we looked to stacks to help reduce
the number of resources which need to download before js is processed on
the client. It was easy to list the resulting set of scripts (css is not
aggregated by tapestry so ignored) a page ends up using so a stack could
be made for each of these heavy pages.
great! but not so great when everything else starts breaking...
its like an opposite of the Java import paradigm - ClassA imports
StringUtils and EJBContainer. ClassB imports StringUtils. Therefore
ClassB must also import EJBContainer ?? no...
On 19/11/2014 10:30 PM, Thiago H de Paula Figueiredo wrote:
On Wed, 19 Nov 2014 07:57:19 -0200, Geoff Callender
<geoff.callender.jumpst...@gmail.com> wrote:
I've never seen this but I probably don't have any stacks that
include a resource that I also reference outside of the stack.
If it's true then it sounds like a bug.
I'm not sure it is. I guess the reasoning behind this is to not have
the user browser download and process the same asset being downloaded
from two or more different URLs: one for the asset itself, plus
another for each stack in which the asset is included. If there wasn't
this behavior and, for example, a component imports one .js file
directly and a page using it includes a stack which includes this .js,
it would be downloaded and executed twice, probably causing bugs.
This way, I believe we should consider each stack as an unit in which
its components don't work unless the other ones are included too. If a
given file is used in one stack but can also be referenced directly or
in another stack, the stack(s) should be refactored.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
