Well, one of the biggest problems is to restore the page to previous
state. Problem with wicket is that you can modify the page numerous
ways during ajax updates and that is very difficult to track. Also
even if we did some kind of revesible deltas (which would be rather
complicated), we would have to fetch it from server on back button,
which itself is an asynchronous task. Now would would happen if user
rapidly clicked back, back, forward buttons? How would we cope with
that? That's just some of the problems we would be facing.

-Matej

On Fri, Aug 29, 2008 at 10:34 AM, Hassan Chafi
<[EMAIL PROTECTED]> wrote:
>
> Yes thanks, I just switched a bunch of pages to using
> HybridUrlCodingStrategy. Too bad about the back button support. I am not
> sure if this is even doable, but I would be fine with a way that exposes to
> me the IPageStore functionality. I will then store pages at convenient times
> for me (for example onClick of AjaxLinks).
>
> I can then using a number of ways intercept back button, get the page from
> the store and redirect to it.
>
> Wouldn't something like this work? Am I missing some big picture item here.
>
> -hc
>
> Matej Knopp-2 wrote:
>>
>>>
>>> Without back button support or a way to manage history, implementing a
>>> single page type of application becomes a bit difficult to do in wicket.
>>> Refreshing the page via F5 should also obviously show the current state
>>> of
>>> the page and not re-instantiate it from scratch.
>> But this is easy to solve even without back button support. Just mount
>> the page using HybridUrlCodingStrategy and you will always get current
>> state on refresh.
>>
>> I don't think there will ever be proper back button support for Wicket
>> ajax. Wicket Ajax support is too generic and all the back button
>> frameworks I looked at are not capable of storing the state wicket
>> would need. Also it's just too fragile.
>>
>> -Matej
>>
>>
>
> --
> View this message in context: 
> http://www.nabble.com/Wicket-1.5-Ajax-tp19189204p19215915.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>

Reply via email to