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�
