Hi Boris,

sorry, I've got distracted by other things: real life :P

This is a bug, so I'll apply my fix to Wicket 7 too - I have to make the aggregator aware of the headers' render tokens.

Regards
Sven


On 10.05.2017 22:32, Boris Goldowsky wrote:
Sven, do you expect your fix for this to get into the next point release of 
Wicket 7, or will it only be in Wicket 8?

Just trying to determine if I need to build a work-around or if I can wait for 
an official fix.

Thanks!

Boris


On 4/25/17, 9:07 PM, "Boris Goldowsky" <bgoldow...@cast.org> wrote:

     Thank you!
https://issues.apache.org/jira/browse/WICKET-6362 Boris On 4/25/17, 6:02 PM, "Sven Meier" <s...@meiers.net> wrote: Hi Boris, this is a bug in ResourceAggregator, please file a Jira issue - I think
         I have a fix ready by tomorrow.
Have fun
         Sven
On 25.04.2017 15:32, Boris Goldowsky wrote:
         > I think Sven is right.
         > Debugging through, it appears to be here in ResourceAggregator:
         >
         >   private void recordHeaderItem(HeaderItem item, Set<HeaderItem> 
depsDone)
         >   {
         >           renderDependencies(item, depsDone);
         >           RecordedHeaderItem recordedItem = 
itemsToBeRendered.get(item);
         >
         >   “recordedItem” ends up as the old header item rather than the new 
one.
         >
         > Bng
         >
         >
         > On 4/24/17, 6:09 PM, "Sven Meier" <s...@meiers.net> wrote:
         >
         >      HI,
         >
         >      this might be caused by ResourceAggregator - it marks items as 
being
         >      rendered, instead of render tokens.
         >
         >      I'll check tomorrow.
         >
         >      Sven
         >
         >
         >      On 24.04.2017 23:41, Martin Grigorov wrote:
         >      > On Mon, Apr 24, 2017 at 11:39 PM, Martin Grigorov 
<mgrigo...@apache.org>
         >      > wrote:
         >      >
         >      >> Hi,
         >      >>
         >      >> On Mon, Apr 24, 2017 at 10:20 PM, Boris Goldowsky 
<bgoldow...@cast.org>
         >      >> wrote:
         >      >>
         >      >>> I have a situation like this:
         >      >>>
         >      >>> public void renderHead(IHeaderResponse response) {
         >      >>>      …
         >      >>>      
response.render(JavaScriptHeaderItem.forReference(resRef,
         >      >>> pageParameters1, “id1”));
         >      >>>      
response.render(JavaScriptHeaderItem.forReference(resRef,
         >      >>> pageParameters2, “id2”));
         >      >>> }
         >      >>>
         >      >>> where same ResourceReference is used for both resources – 
the different
         >      >>> page parameters point it to different actual Resources.
         >      >>>
         >      >>> However, the check for uniqueness of header items seems to 
consider them
         >      >>> equal, despite the different PageParameters and different 
IDs, and only one
         >      >>> of them actually gets rendered in the page head.
         >      >>>
         >      >> Which check exactly do you refer ?
         >      >>
         >      >> 
org.apache.wicket.markup.head.internal.HeaderResponse#markItemRendered()
         >      >> does such check by calling 
org.apache.wicket.markup.head.HeaderItem#
         >      >> getRenderTokens().
         >      >> 
org.apache.wicket.markup.head.JavaScriptReferenceHeaderItem#getRenderTokens()
         >      >> uses the url and the id. The url contains the parameters.
         >      >> All looks good to me!
         >      >>
         >      > The other check is at jQuery.Head.containsElement() 
(wicket-ajax-jquery.js)
         >      > and it uses the value "src", i.e. it should not match because 
of the
         >      > different parameters.
         >      >
         >      >>
         >      >>> Is this a bug, or is there a way to force the two items to 
both be
         >      >>> included?
         >      >>>
         >      >>> I’m using Wicket 7.5.0.
         >      >>>
         >      >>> Boris
         >      >>>
         >      >>>
         >      >>>
         >      >>>
         >      >>>
         >
         >
         >      
---------------------------------------------------------------------
         >      To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
         >      For additional commands, e-mail: users-h...@wicket.apache.org
         >
         >
         >
         >
         > ---------------------------------------------------------------------
         > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
         > For additional commands, e-mail: users-h...@wicket.apache.org
         >
---------------------------------------------------------------------
         To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
         For additional commands, e-mail: users-h...@wicket.apache.org
?B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�?�?[��X��ܚX�K??K[XZ[?�?\�\��][��X��ܚX�P?�X��]?�\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�?�??K[XZ[?�?\�\��Z?[???�X��]?�\?X�?K�ܙ�B�


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to