AjaxTimer clearTimeout

[James McLaughlin-3]

Hi all,
I have a panel with an AjaxTimerBehavior that can be replaced through an AjaxLink by another panel. However, this leaves the AjaxTimerBehaviors setTimeout behind  to fire off after the replacement. When it fires  and wicket can't resolve the requested component, a redirect to the containing page occurs, causing an unsightly refresh and flicker.

First, is there a way to short circuit this redirect?

If not, what would be a good pattern for preventing this timeout when the component is replaced?

I think the best way would be to wrap the javascript timer function in a check  to see if it should still fire. This will be easy to do if generated markupIds are unique even when one component replaces another. Can someone confirm that is the case? Another way would be to capture the timeoutId and clear it when the component gets replaced. That code already smells and it hasn't even left my brain :).

Any other ideas?

thx,
jim

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@...
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Eelco Hillenius]

On 3/7/07, James McLaughlin <jomclaughlin@...> wrote:

> Hi all,
> I have a panel with an AjaxTimerBehavior that can be replaced through an
> AjaxLink by another panel. However, this leaves the AjaxTimerBehaviors
> setTimeout behind  to fire off after the replacement. When it fires  and
> wicket can't resolve the requested component, a redirect to the containing
> page occurs, causing an unsightly refresh and flicker.
>
> First, is there a way to short circuit this redirect?
>
> If not, what would be a good pattern for preventing this timeout when the
> component is replaced?
>
> I think the best way would be to wrap the javascript timer function in a
> check  to see if it should still fire. This will be easy to do if generated
> markupIds are unique even when one component replaces another. Can someone
> confirm that is the case? Another way would be to capture the timeoutId and
> clear it when the component gets replaced. That code already smells and it
> hasn't even left my brain :).

Hmmm, yeah, that's interesting. Maybe others thought of this before,
but I hadn't. So we can add header (/body?) contributions via ajax
dynamically now. What we want here is the opposite: remove them when
the linked component was removed/ replaced, right?

Eelco

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@...
https://lists.sourceforge.net/lists/listinfo/wicket-user

[James McLaughlin-3]

On 3/9/07, Eelco Hillenius <eelco.hillenius@...> wrote:

Hmmm, yeah, that's interesting. Maybe others thought of this before,
but I hadn't. So we can add header (/body?) contributions via ajax
dynamically now. What we want here is the opposite: remove them when
the linked component was removed/ replaced, right?

Eelco

 

Right, my first instinct was to ask for an onRemove as part of the component/behavior lifecycle. But with larger issues looming for wicket, I decided to hold off. Turns out my problem with the AjaxTimer was pretty straight forward to solve since wicket generates unique ids for all components even if they occupy the same place in the hierarchy.

In case anyone is interested, you just need to override getCallbackScript :

 @Override
            protected CharSequence getCallbackScript(boolean recordPageVersion)
            {
                String mId = getComponent().getMarkupId();
                StringBuilder sb = new StringBuilder("exec_func(function() { ");
                sb.append("var el = wicketGet('" + mId + "'); ");
                sb.append("if(null != el) {");
                sb.append(super.getCallbackScript(recordPageVersion));
                sb.append("}");
                sb.append("})");
               
                return sb.toString ();
            }

This just wraps it in an anonymous func that checks to see if the dom element is still there before calling the timer. exec_func is necessary because the anonymous function is passed to setTimeout as string and ff is not happy with that (it does only what it says). But it is a hack and I would love to have a wicket way of doing this.

Thanks for getting back to me.

best,

jim

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@...
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Matej Knopp]

Hi,

I'm afraid there's no easy solution. But two thoughts are quiete right.
Either you can clearTimeout, or wrap the setTimeout method  callback
(not the settimeout itself!) to check a condition whether it actually
can fire ajax request to server. But for both these you will need to
slightly modify AbstractAjaxTimerBehavior.

-Matej

James McLaughlin wrote:

> Hi all,
> I have a panel with an AjaxTimerBehavior that can be replaced through an
> AjaxLink by another panel. However, this leaves the AjaxTimerBehaviors
> setTimeout behind  to fire off after the replacement. When it fires  and
> wicket can't resolve the requested component, a redirect to the
> containing page occurs, causing an unsightly refresh and flicker.
>
> First, is there a way to short circuit this redirect?
>
> If not, what would be a good pattern for preventing this timeout when
> the component is replaced?
>
> I think the best way would be to wrap the javascript timer function in a
> check  to see if it should still fire. This will be easy to do if
> generated markupIds are unique even when one component replaces another.
> Can someone confirm that is the case? Another way would be to capture
> the timeoutId and clear it when the component gets replaced. That code
> already smells and it hasn't even left my brain :).
>
> Any other ideas?
>
> thx,
> jim
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@...
> https://lists.sourceforge.net/lists/listinfo/wicket-user

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@...
https://lists.sourceforge.net/lists/listinfo/wicket-user

[MattClark]

I ran into this tonight as well.  Would it be possible to have James' code below, or a better version if it exists, added to AjaxTimerBehavior?  I can't think of a case where this behavior would be undesirable.  Let me know if I should file a JIRA.

James McLaughlin-3 wrote:

In case anyone is interested, you just need to override getCallbackScript :

 @Override
            protected CharSequence getCallbackScript(boolean
recordPageVersion)
            {
                String mId = getComponent().getMarkupId();
                StringBuilder sb = new StringBuilder("exec_func(function() {
");
                sb.append("var el = wicketGet('" + mId + "'); ");
                sb.append("if(null != el) {");
                sb.append(super.getCallbackScript(recordPageVersion));
                sb.append("}");
                sb.append("})");

                return sb.toString();
            }