On Thu, Jan 17, 2013 at 12:53 PM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Hi,
>
> I see there is
>
> /**
>  * Remove any scheduled timers on the removed element.
>  * This wont remove the timer for elements which are children of the
> removed one.
>  */
> Wicket.Event.subscribe('/dom/node/removing', function(jqEvent, element) {
> var id = element.id;
> if (Wicket.TimerHandles && Wicket.TimerHandles[id]) {
> window.clearTimeout(Wicket.TimerHandles[id]);
> delete Wicket.TimerHandles[id];
> }
> });
>
> would this take care of automatically removing the behavior at client side?
>

Only if the html element with the registered timer behavior is
removed/replaced.
If a parent element is removed/replaced then this wont be able to clean up.


>
> On Thu, Jan 17, 2013 at 11:49 AM, Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
> > Or maybe "mark" those behaviors as "if it fails do not throw exception".
> > That way when call back comes behavior will be removed form client side
> and
> > failing request ignored?
> >
> >
> > On Thu, Jan 17, 2013 at 11:44 AM, Sven Meier <s...@meiers.net> wrote:
> >
> >> Yeah, this is what I wrote in my first comment:
> >>
> >> "Thus the next pending Ajax request comes through, since wicket-ajax's
> >> defaultPrecondition sees the markupId still present in the dom."
> >>
> >> Perhaps we have to cancel out all scheduled callbacks for components
> >> which are replaced via Ajax.
> >>
> >> Sven
> >>
> >>
> >> On 01/17/2013 11:34 AM, Ernesto Reinaldo Barreiro wrote:
> >>
> >>> Hi,
> >>>
> >>> On Thu, Jan 17, 2013 at 11:17 AM, Sven Meier <s...@meiers.net> wrote:
> >>>
> >>>           @Override
> >>>>
> >>>>>          public void detach(Component component)
> >>>>>          {
> >>>>>                  AjaxRequestTarget target =
> >>>>> component.getRequestCycle().**
> >>>>>
> >>>>> find(AjaxRequestTarget.class);
> >>>>>                  if (target != null)
> >>>>>                  {
> >>>>>                          stop(target);
> >>>>>                  }
> >>>>>                  super.detach(component);
> >>>>>          }
> >>>>>
> >>>>>
> >>>> A small nitpick:
> >>>> Removing a component in an ART might not be the only reason why
> >>>> #detach()
> >>>> is called. A developer might call component#detach() to force a LDM to
> >>>> reload on the next render.
> >>>>
> >>>> Sven
> >>>>
> >>>>
> >>>>  Just another caveat: what happens if during rending time, before call
> >>> AJAX
> >>> response is processed, the behavior is re-fired at client side?
> Wouldn't
> >>>   this produce a component not found exception?
> >>>
> >>>
> >>
> >
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
> > Antilia Soft
> > http://antiliasoft.com/ <http://antiliasoft.com/antilia>
> >
>
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
> Antilia Soft
> http://antiliasoft.com/ <http://antiliasoft.com/antilia>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>

Reply via email to