Hi,

On Sun, Nov 25, 2012 at 9:51 AM, Sven Meier <s...@meiers.net> wrote:

> Make a copy of AbstractAjaxTimerBehavior and let it be stoppable from
> onTimer():
>
> diff --git 
> a/wicket-core/src/main/java/**org/apache/wicket/ajax/**AbstractAjaxTimerBehavior.java
> b/wicket-core/src/main/java/**org/apache/wicket/ajax/**
> AbstractAjaxTimerBehavior.java
> index 3071875..b982a39 100644
> --- a/wicket-core/src/main/java/**org/apache/wicket/ajax/**
> AbstractAjaxTimerBehavior.java
> +++ b/wicket-core/src/main/java/**org/apache/wicket/ajax/**
> AbstractAjaxTimerBehavior.java
> @@ -131,8 +131,11 @@
>          {
>              onTimer(target);
>
> -            target.getHeaderResponse().**render(
> - OnLoadHeaderItem.forScript(**getJsTimeoutCall(**updateInterval)));
> +            if (!isStopped())
>

But this code is already in : if (!isStopped() && isEnabled(getComponent()))
How the second "if (!isStopped())" fixes the issue ?


> +            {
> +                target.getHeaderResponse().**render(
> + OnLoadHeaderItem.forScript(**getJsTimeoutCall(**updateInterval)));
> +            }
>          }
>      }
>
> You could create a jira issue too.


Additionally there are two global Ajax listeners at the bottom of
wicket-ajax-jquery.js which purpose is to remove any obsolete timers.
I haven't debugged the application so I'm not sure where exactly is the
problem.


>
>
> Sven
>
>
>
> On 11/25/2012 01:13 AM, Oliver Zemann wrote:
>
>> Unfortunately this is not a solution as i have about 30 different panels.
>> And i guess at least 10 of them should later use JS. With the approach you
>> suggested i would have to check which panel should be displayed and load
>> that (switch/case with 10 different panels). I guess that would also lead
>> in heavy mixing the panels with the HomePage (BasePage) (destroying
>> reusability).
>>
>> There is also no way for me to create a "flow based" dialogue as this is
>> done in the backend controller which only tells me which panel to load.
>>
>> So there is no other way to go?
>>
>> Am 24.11.2012 22:57, schrieb Sven Meier:
>>
>>> After the timer has fired, AbstractAjaxTimerBehavior automatically
>>> registers another timeout for the form inside PanelOne.
>>> But at that point PanelOne is no longer in the component tree, it's
>>> replaced by PanelTwo already.
>>>
>>> I'd recommend adding the behavor to the container instead:
>>>
>>>         final WebMarkupContainer wmc = new WebMarkupContainer("container"
>>> **);
>>>         wmc.add(new AbstractAjaxTimerBehavior(**Duration.seconds(5)) {
>>>             @Override
>>>             protected void onTimer(AjaxRequestTarget target) {
>>>                 PanelTwo two = new PanelTwo("panel");
>>>                 wmc.addOrReplace(two);
>>>                 target.add(wmc);
>>>
>>>                 stop(target);
>>>             }
>>>         });
>>>         add(wmc);
>>>
>>>         wmc.add(new PanelOne("panel"));
>>>
>>> This way you won't have to pass 'wmc' to PanelOne any longer.
>>>
>>> Sven
>>>
>>> On 11/24/2012 10:04 PM, Oliver Zemann wrote:
>>>
>>>> The problem is that this leads to a Page not found error. The problem
>>>> is that the Panel which should be replaced is still looked up in the
>>>> findPage() method. But findPage() returns null on that component, so this
>>>> error is thrown.
>>>>
>>>> Am 24.11.2012 21:48, schrieb Sven Meier:
>>>>
>>>>> What is the problem?
>>>>>
>>>>> Sven
>>>>>
>>>>> On 11/24/2012 08:22 PM, Oliver Zemann wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> i created a small wicket application to show my problem:
>>>>>> https://github.com/olze/**WicketPanelReplace<https://github.com/olze/WicketPanelReplace>
>>>>>>
>>>>>> The first panel gets displayed, after a few seconds it should be
>>>>>> replaced by the second panel. Is there any way to achieve this behavior
>>>>>> with that kind of architecture?
>>>>>>
>>>>>> If not, how should a ajax based panel wizard work? Any
>>>>>> recommendations?
>>>>>>
>>>>>> Thanks in advance.
>>>>>>
>>>>>> Oli
>>>>>>
>>>>>> ------------------------------**------------------------------**
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: 
>>>>>> users-unsubscribe@wicket.**apache.org<users-unsubscr...@wicket.apache.org>
>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail: 
>>>>> users-unsubscribe@wicket.**apache.org<users-unsubscr...@wicket.apache.org>
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: 
>>>> users-unsubscribe@wicket.**apache.org<users-unsubscr...@wicket.apache.org>
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: 
>>> users-unsubscribe@wicket.**apache.org<users-unsubscr...@wicket.apache.org>
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: 
>> users-unsubscribe@wicket.**apache.org<users-unsubscr...@wicket.apache.org>
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: 
> users-unsubscribe@wicket.**apache.org<users-unsubscr...@wicket.apache.org>
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


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

Reply via email to