Re: Stateless page with AjaxSelfUpdatingTimerBehavior

[Sven Meier]

Hi,

you can make any Ajax behavior stateless as follows:

        component.setMarkupId("stable-id");
        add(component);

        component.add(new 
AjaxSelfUpdatingTimerBehavior(Duration.seconds(5)) {

            @Override
            public boolean getStatelessHint(Component component) {
                return true;
            }
        });

Note that you have to use a stable markup id for the component, 
otherwise it cannot be updated.


Have fun
Sven


On 23.06.20 17:21, Zbynek Vavros wrote:

Hi,

We have a page with AjaxSelfUpdatingTimerBehavior and now one of our
customers is complaining about "weird" behavior when this page is opened in
multiple browser tabs (yeah yeah we told him not to do it...).

What happens is that after opening this page in new tab, the previous tab
gets ajax redirect on mentioned timer.

After some digging I found out that this is happening because the page is
stateful.
Excerpt from Wicket code:

// If the page is stateful then we cannot assume that the listener
interface is
// invoked on its initial state (right after page initialization) and that
its
// component and/or behavior will be available. That's why the listener
interface
// should be ignored and the best we can do is to re-paint the newly
constructed
// page.

I did use StatelessChecker (very useful!) and found out that the reason is
this AjaxSelfUpdatingTimerBehavior.

Googling around I found this thread from 2011 -
http://apache-wicket.1842946.n4.nabble.com/Stateless-page-with-an-auto-update-section-td3795927.html.
The suggestion here is to "roll your own timer behavior".

Well, I spent some time with Wicket already but this is beyond my
knowledge. Can anyone please point me the right direction? Is this even
possible? I just have to say the AjaxSelfUpdatingTimerBehavior must stay -
this page displays progress bar of background task that is non-negotiable.

Thanks,
Zbynek



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

Stateless page with AjaxSelfUpdatingTimerBehavior

[Zbynek Vavros]

Hi,

We have a page with AjaxSelfUpdatingTimerBehavior and now one of our
customers is complaining about "weird" behavior when this page is opened in
multiple browser tabs (yeah yeah we told him not to do it...).

What happens is that after opening this page in new tab, the previous tab
gets ajax redirect on mentioned timer.

After some digging I found out that this is happening because the page is
stateful.
Excerpt from Wicket code:

// If the page is stateful then we cannot assume that the listener
interface is
// invoked on its initial state (right after page initialization) and that
its
// component and/or behavior will be available. That's why the listener
interface
// should be ignored and the best we can do is to re-paint the newly
constructed
// page.

I did use StatelessChecker (very useful!) and found out that the reason is
this AjaxSelfUpdatingTimerBehavior.

Googling around I found this thread from 2011 -
http://apache-wicket.1842946.n4.nabble.com/Stateless-page-with-an-auto-update-section-td3795927.html.
The suggestion here is to "roll your own timer behavior".

Well, I spent some time with Wicket already but this is beyond my
knowledge. Can anyone please point me the right direction? Is this even
possible? I just have to say the AjaxSelfUpdatingTimerBehavior must stay -
this page displays progress bar of background task that is non-negotiable.

Thanks,
Zbynek

Re: JS - defer automatic?

[Rob Audenaerde]

Hi Sven,

Thanks! that is really helpful, until now I manually added ,true to each
JavaScriptHeaderItem :/ Wish I knew this before :)

For all others reading this, it is as simple as adding this:

setHeaderResponseDecorator(response -> new ResourceAggregator(new
JavaScriptDeferHeaderResponse(response)));

to the Application.init()

Cheers!
-Rob


On Mon, Jun 22, 2020 at 6:41 PM Sven Meier  wrote:

> Hi Rob,
>
> have you tried JavaScriptDeferHeaderResponse?
>
> And here's some background on how we arrived at this solution:
>
> https://issues.apache.org/jira/browse/WICKET-6498
>
> Have fun
> Sven
>
>
> On 22.06.20 13:23, Rob Audenaerde wrote:
> > Hi all,
> >
> > I'm trying to increase the google-page-speed of some WicketApplication.
> It
> > seems most jquery javascript is 'blocking', i.e. not usign 'defer'.
> >
> > For example this google-chrome-audit section:
> >
> > URL
> > Size
> > Potential Savings
> > …jquery/jquery-2.2.4-ver-F9E….js
> > <
> http://localhost:8080/wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-2.2.4-ver-F9EE266EF993962AD59E804AD9DEBE66.js
> >
> > (localhost)
> > 167 KB
> > 2,560 ms
> > …com.googlecode.wicket.jquery.ui.resource.JQueryUIR…/jquery-….js
> > <
> http://localhost:8080/wicket/resource/com.googlecode.wicket.jquery.ui.resource.JQueryUIResourceReference/jquery-ui-ver-0A819924D70A18322660DEE759225D2B.js
> >
> > (localhost)
> > 494 KB
> > 4,360 ms
> > …js/wicket-aj….js
> > <
> http://localhost:8080/wicket/resource/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/res/js/wicket-ajax-jquery-ver-3A8C326A8436172FC95523D517EBC88B.js
> >
> > (localhost)
> > 86 KB
> > 1,660 ms
> > /style.css 
> > (localhost)
> > 4 KB
> > 310 ms
> >
> > Is there a reason why this is all non-deferred? Or an easy way to change
> > this? Most functionality is added in an DomReady event anyway.
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>