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 <lance.j...@googlemail.com> wrote: > 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 is worthy of a Jira issue. > > On Tuesday, 6 March 2012, Jochen Berger <foober...@googlemail.com> wrote: >> 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 ability to cache >>> them in the client's browser. >> >> Right, I missed that ignoring duplicates would break the stack assembling feature. But I still see problems with the current behavior. I think we should find a way to prevent someone from creating stack setups like mine (a single asset being used in multiple stacks). Maybe JavaScriptStackSource(Impl) could log a warning or even throw an exception if that is done. What do you think? >> >> Jochen >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >>
