As a workaround you could use this:
getHeaderResponseDecorators().add( (response) -> {
if (RequestCycle.get().find(AjaxRequestTarget.class) == null) {
response = new JavaScriptDeferHeaderResponse(response);
}
return response;
Hi Bas,
that seems to be broken since
https://issues.apache.org/jira/browse/WICKET-6703
The JS is correctly collected by PartialPageUpdate, but then sent
through the response decorators once again, thus being wrapped in a
'DOMContentLoaded' listener.
Please open a Jira issue.
Regards
Hi Bas,
your attachment didn't make it through the mailing list.
Can you point me to where I can download it from?
Thanks
Sven
On 31.01.22 14:51, Bas Gooren wrote:
Hi,
We are experimenting with the JavaScriptDeferHeaderResponse, but out
of the box it doesn’t work correctly for us.
We are
Thank you for your answer.
This helped me and I have looked a little bit deeper into the IPageStore and
WicketObjects implementations.
Greetings Matthias
-Ursprüngliche Nachricht-
Von: Sven Meier
Gesendet: Montag, 31. Januar 2022 21:59
An: users@wicket.apache.org
Betreff: Re:
ti 1. helmik. 2022 klo 13.32 Wayne W (waynemailingli...@gmail.com)
kirjoitti:
> Thanks all for your replies.
> Food for thought there.
>
> WicketTester seems the 'better' solution, but I'm trying to hand this over
> to a QA person who cannot program. Ernesto - I think it would be a massive
>
Thanks all for your replies.
Food for thought there.
WicketTester seems the 'better' solution, but I'm trying to hand this over
to a QA person who cannot program. Ernesto - I think it would be a massive
undertaking for use to get the css paths working well enough so that there
was some