Hi,
Am 06.03.2012 10:48, schrieb Lance Java:
For the record, I don't think that it's an error to have two stacks sharing
the same artifact in your application.
I think the error exists when a page is attempting to import two stacks
which share the same artifact.
Correct, but that can only be
For the record, I don't think that it's an error to have two stacks sharing
the same artifact in your application.
I think the error exists when a page is attempting to import two stacks
which share the same artifact.
On Tuesday, 6 March 2012, Lance Java wrote:
> I agree that tapestry could be n
I agree that tapestry could be nice and at the least should log a warning
to the console in this case.
As you said, throwing an exception would be good too... at least in
development mode. Not sure but perhaps it should throw exceptions if some
(configurable) symbol is set to "true".
I think this
Hi,
Am 05.03.2012 11:41, schrieb Lance Java:
The javascript stack concept exists so that the stack remains constant and
can be cached by the client's browser.
You are now asking to break this contract and have stacks be dynamic based
on what components are on a page which would eliminate the ab
The javascript stack concept exists so that the stack remains constant and
can be cached by the client's browser.
You are now asking to break this contract and have stacks be dynamic based
on what components are on a page which would eliminate the ability to cache
them in the client's browser.
I
Hi,
I just observed that if I add a JS library to two different stacks and
import them in a page, that asset is added to the page twice.
This happens because JavaScriptSupportImpl does check for duplicate
stylesheets (L 327) and stacks (L 294) but not for duplicate scripts. Is
that expected or
