That would be the ideal situation where if a stack was defined containing CompJS, then if something references CompJS the stack is brought in. A simpler thing to do would be to simply remove the individual call to CompJS if the stack containing is imported, but this is less useful. Either would be far superior to the current behaviour.
I've raised TAP5-1279 for this issue. Is this likely to get fixed in the next 3 weeks? If not then I'll need to plan accordingly. > -----Original Message----- > From: Howard Lewis Ship [mailto:hls...@gmail.com] > Sent: 20 September 2010 18:48 > To: Tapestry users > Subject: Re: [T5.2] JavaScript combination > > Those are great comments; I had thought about imported JS libraries > "dragging in" a stack and I can't remember why I abandoned it. Perhaps > I was trying to be properly agile (don't implement it until there's a > need). > > You case is interesting; a piece of code that blindly imports a JS > that is already part of a stack. And yes, I think you may be right, > that that should trigger an import of the stack itself. > > On Mon, Sep 20, 2010 at 6:26 AM, Blower, Andy > <andy.blo...@proquest.co.uk> wrote: > > I've created my first stack, and I'm slightly puzzled about the value > of this - or maybe I've simply done something wrong. > > > > The stack mechanism doesn't seem to be removing duplicate javascript > references as I was expecting it to do. Tapestry JS has always worked > on a component requesting the JS assets it needs and then Tapestry > ensured that each required JS asset was added to the page only once, > even if several components asked for the same JS asset. The stack > system doesn't seem to follow this... > > > > For example, say I have a component "Comp" that specifies it needs > the "CompJS" asset, and is used on pages "Page1" and "Page2". If Page1 > doesn't have much more to it and only needs CompJS then that's what > should be included by Tapestry, since Comp @Import's CompJS. All well > and good. > > > > Now, if Page2 has a lot of other components with their own JS files > which are then combined into a T5 stack and requested by the page's > @Import then I would not expect CompJS to be referenced on the page > since it's already included in the stack file. It seems to be in T5.2.0 > with my testing. > > > > Unless I'm mistaken about how this is working, then I fail to see how > this stack mechanism provides much benefit over simply putting all my > projects' JS into a single file and referencing that in each page. The > only advantage is to split it up into easily editable chunks, I still > have to manage the aggregation. I think it's going to be very easy to > get duplicate JS in the rendered html page with this system. > > > > Is this working as intended or any I missing something here? > > > > Thanks, > > > > Andy > > > >> -----Original Message----- > >> From: Blower, Andy [mailto:andy.blo...@proquest.co.uk] > >> Sent: 20 September 2010 11:28 > >> To: 'Tapestry users' > >> Subject: RE: [T5.2] JavaScript combination > >> > >> > >> > >> > -----Original Message----- > >> > From: Howard Lewis Ship [mailto:hls...@gmail.com] > >> > Sent: 17 September 2010 22:31 > >> > To: Tapestry users > >> > Subject: Re: [T5.2] JavaScript combination > >> > > >> > On Fri, Sep 17, 2010 at 9:20 AM, Blower, Andy > >> > <andy.blo...@proquest.co.uk> wrote: > >> > > A few questions: > >> > > > >> > > Is there any documentation of the new JavaScript combination > >> > functionality added to fix TAP5-769 in 5.2, specifically about > >> stacks? > >> > I can't see any, but before I dive into code/javadoc I thought I'd > >> ask. > >> > > >> > Well, there's JavaDoc. > >> > > >> I will use that then. > >> > >> > > > >> > > Why aren't the prototype & scriptaculous libraries combined into > a > >> > stack by default? > >> > > > >> > > >> > They are in production; by default in development the aggregation > >> > logic is turned off, as it makes it much faster/easier to debug on > >> the > >> > client side. There's a symbol you can override to enable > aggregation > >> > in development mode. > >> > >> Right, I saw a couple of scriptaculous libraries separate and jumped > to > >> a conclusion. Why isn't Tap5.2 using the latest version of > >> scriptaculous? (1.8.3) > >> > >> > > What's the status of minifying css & js? > >> > > > >> > > >> > No progress on that; concentrating on documentation and getting > 5.2 > >> > out the door right now. > >> > >> Fair enough > >> > >> > >> -------------------------------------------------------------------- > - > >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > >> For additional commands, e-mail: users-h...@tapestry.apache.org > >> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
