You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Blower, Andy" <An...@proquest.co.uk> on 2010/09/17 18:20:52 UTC
[T5.2] JavaScript combination
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.
Why aren't the prototype & scriptaculous libraries combined into a stack by default?
What's the status of minifying css & js?
Thanks,
Andy.
RE: [T5.2] JavaScript combination
Posted by "Blower, Andy" <An...@proquest.co.uk>.
Yes, that's working beautifully. Now I know about it... ;-)
Thanks Howard!
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: 11 October 2010 17:45
> To: Tapestry users
> Subject: Re: [T5.2] JavaScript combination
>
> Yes, stacks can have dependencies on other stacks. Is that not working
> correctly?
>
> On Mon, Oct 11, 2010 at 9:19 AM, Blower, Andy
> <An...@proquest.co.uk> wrote:
> > I've been trying the new stack implementation in T5.2.1 and it's much
> better. I am having a problem with the order they're put into the page.
> It seems (I'm guessing/trying to spot a pattern here) to be dependent
> on the first import of a stack element which means the stacks can
> easily be requested in an order that means that extensions appear
> before the definitions of what they're trying to extend. This is a real
> problem, especially when using modules.
> >
> > Is there a way to define the order JS stacks are outputted?
> >
> >
> >> -----Original Message-----
> >> From: Blower, Andy [mailto:Andy.Blower@proquest.co.uk]
> >> Sent: 21 September 2010 10:08
> >> To: 'Tapestry users'
> >> Subject: RE: [T5.2] JavaScript combination
> >>
> >> 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:hlship@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
> >> > <An...@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.Blower@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:hlship@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
> >> > >> > <An...@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-unsubscribe@tapestry.apache.org
> >> > >> For additional commands, e-mail: users-help@tapestry.apache.org
> >> > >>
> >> > >
> >> > >
> >> > >
> >> > > ----------------------------------------------------------------
> ---
> >> --
> >> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> > > For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
> >> > For additional commands, e-mail: users-help@tapestry.apache.org
> >> >
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> -
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.2] JavaScript combination
Posted by Howard Lewis Ship <hl...@gmail.com>.
Yes, stacks can have dependencies on other stacks. Is that not working
correctly?
On Mon, Oct 11, 2010 at 9:19 AM, Blower, Andy
<An...@proquest.co.uk> wrote:
> I've been trying the new stack implementation in T5.2.1 and it's much better. I am having a problem with the order they're put into the page. It seems (I'm guessing/trying to spot a pattern here) to be dependent on the first import of a stack element which means the stacks can easily be requested in an order that means that extensions appear before the definitions of what they're trying to extend. This is a real problem, especially when using modules.
>
> Is there a way to define the order JS stacks are outputted?
>
>
>> -----Original Message-----
>> From: Blower, Andy [mailto:Andy.Blower@proquest.co.uk]
>> Sent: 21 September 2010 10:08
>> To: 'Tapestry users'
>> Subject: RE: [T5.2] JavaScript combination
>>
>> 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:hlship@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
>> > <An...@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.Blower@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:hlship@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
>> > >> > <An...@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-unsubscribe@tapestry.apache.org
>> > >> For additional commands, e-mail: users-help@tapestry.apache.org
>> > >>
>> > >
>> > >
>> > >
>> > > -------------------------------------------------------------------
>> --
>> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > > For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: [T5.2] JavaScript combination
Posted by "Blower, Andy" <An...@proquest.co.uk>.
I've been trying the new stack implementation in T5.2.1 and it's much better. I am having a problem with the order they're put into the page. It seems (I'm guessing/trying to spot a pattern here) to be dependent on the first import of a stack element which means the stacks can easily be requested in an order that means that extensions appear before the definitions of what they're trying to extend. This is a real problem, especially when using modules.
Is there a way to define the order JS stacks are outputted?
> -----Original Message-----
> From: Blower, Andy [mailto:Andy.Blower@proquest.co.uk]
> Sent: 21 September 2010 10:08
> To: 'Tapestry users'
> Subject: RE: [T5.2] JavaScript combination
>
> 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:hlship@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
> > <An...@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.Blower@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:hlship@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
> > >> > <An...@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-unsubscribe@tapestry.apache.org
> > >> For additional commands, e-mail: users-help@tapestry.apache.org
> > >>
> > >
> > >
> > >
> > > -------------------------------------------------------------------
> --
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: [T5.2] JavaScript combination
Posted by "Blower, Andy" <An...@proquest.co.uk>.
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:hlship@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
> <An...@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.Blower@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:hlship@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
> >> > <An...@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-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.2] JavaScript combination
Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<An...@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.Blower@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:hlship@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
>> > <An...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: [T5.2] JavaScript combination
Posted by "Blower, Andy" <An...@proquest.co.uk>.
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.Blower@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:hlship@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
> > <An...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: [T5.2] JavaScript combination
Posted by "Blower, Andy" <An...@proquest.co.uk>.
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@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
> <An...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.2] JavaScript combination
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Fri, Sep 17, 2010 at 9:20 AM, Blower, Andy
<An...@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.
>
> 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.
> What's the status of minifying css & js?
>
No progress on that; concentrating on documentation and getting 5.2
out the door right now.
> Thanks,
>
> Andy.
>
--
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org