Hi Martin,

> AFAIU Ismael wanted each request to instantiate a new page instance. 

ah, ok. I thought he did this to avoid the same exception like me ...

> Recently I wrote such integration between Wicket and 
> http://tkyk.github.com/jquery-history-plugin/ for a client. 

I guess nothing open source :) ?

> But this will have to wait for Wicket 1.6+.

ok. but I'll try to make use of HistoryAjaxBehavior in the mean time :)

Regards,
Peter.

> Hi Peter,
>
> AFAIU Ismael wanted each request to instantiate a new page instance. That's
> why I suggested either use completely stateless page or use a mapper which
> will create a new instance every time. And this should be combined with
> #disableCaching() so that the browser hits the server every time.
>
> For your case you'll need something that supports (emulates support for)
> Ajax back button.
> Recently I wrote such integration between Wicket and
> http://tkyk.github.com/jquery-history-plugin/ for a client. It is based on
> the idea in my previous solution - HistoryAjaxBehavior but now it is more
> advanced. It is based on a mix between browser events (popstate or
> hashchange) + Wicket 1.5 events.
>
> Otherwise Igor started even more advanced solution at
> https://github.com/ivaynberg/wicket/tree/ajax-history. But this will have to
> wait for Wicket 1.6+.
>
> On Thu, Apr 21, 2011 at 2:52 PM, Peter Karich <[email protected]> wrote:
>
>>  Hi Martin,
>>
>> I'm using the same technic in 1.4 to avoid exceptions with ajax +
>> backbutton(not sure if this is true for Ismael too):
>>
>>  * click on an ajax linkA, and click another one.
>>  * hitting back button
>>  * clicking again ajax linkA
>>  * WicketRuntimeException: component
>> filterPanel:filterNames:1:filterValues:2:filterValueLink not found on
>> page de.jetwick.ui.HomePage
>>
>> So it wouldn't be an option, at least not for me, to avoid that via
>> bookmarkable mappings or something.
>> Or am I wrong? How would you avoid the exeption mentioned above?
>>
>> Then I followed those suggestions:
>>
>>
>> http://www.richardnichols.net/2010/03/apache-wicket-force-page-reload-to-fix-ajax-back/
>>
>> http://blogs.atlassian.com/developer/2007/12/cachecontrol_nostore_considere.html
>>
>> But I'm sure there must be a cleaner way e.g. via HistoryAjaxBehavior or
>> reallysimplehistory.
>>
>> Any hints?
>>
>> Regards,
>> Peter.
>>
>>> Hi,
>>>
>>> In 1.5 there is
>> org.apache.wicket.request.http.WebResponse.disableCaching()
>>> which does the same as you did. But this is not related to your problem.
>>>
>>> When reloading the page Wicket will re-render the same page if it is
>>> stateful, i.e. there is a special parameter in the URL, e.g.
>>> ?2&something=else - here '2' means the second version.
>>> To reload a new instance of the page it has to be either stateless or
>>> bookmarkable.
>>> By default bookmarkable means loaded with BookmarkableMapper, the URL
>> looks
>>> like /wicket/bookmarkable/com.example.MyPage, but if you don't like this
>> URL
>>> then you can create your own IRequestMapper which will be something
>> between
>>> BookmarkableMapper and MountedMapper.
>>>
>>>
>>> On Wed, Apr 20, 2011 at 5:29 PM, Ismael Hasan <
>> [email protected]
>>>> wrote:
>>>> Hello.
>>>>
>>>> I am facing the following problem when migrating from Wicket 1.4.16 to
>>>> 1.5 RC3. First, I'll explain what I want to accomplish, how I do that
>>>> in 1.4.16 and the result obtained. Next, I'll explain how I try to do
>>>> the same wich 1.5 RC3, and which are the results I get.
>>>>
>>>> 1.- I want all of the pages in my web application to avoid caching, so
>>>> they are loaded every time I use the back or reload buttons in the web
>>>> application. To accomplish this, I use the following code in my
>>>> BasePage class:
>>>>        @Override
>>>>        protected void configureResponse() {
>>>>                super.configureResponse();
>>>>                WebResponse response =
>>>> getWebRequestCycle().getWebResponse();
>>>>                response.setHeader("Cache-Control",
>>>>                                "no-cache, max-age=0,must-revalidate,
>>>> no-store");
>>>>        }
>>>> By doing this, every time I reload a page from a browser, and every
>>>> time I use the back button on the browser, the page is fully reloaded:
>>>> it's constructor in the Java class is called, and every item in the
>>>> page is reloaded.
>>>>
>>>> 2.- To accomplish the same thing in Wicket 1.5, I use following code
>>>> in my BasePage class:
>>>>        @Override
>>>>        protected void configureResponse() {
>>>>                super.configureResponse();
>>>>                WebResponse response = (WebResponse)
>>>> getRequestCycle().getResponse();
>>>>                response.setHeader("Cache-Control",
>>>>                                "no-cache, max-age=0,must-revalidate,
>>>> no-store");
>>>>        }
>>>> The problem is that when I hit the back button or the reload button in
>>>> the browser, the constructor of the page is not called, and so the
>>>> page is not fully reloaded. If the back button is used, the
>>>> applications throws  "java.lang.ClassCastException:
>>>> javax.swing.tree.DefaultMutableTreeNode cannot be cast to
>>>> java.lang.String".I think this is motivated because the tree is
>>>> created via Ajax, and since the constructor of the page is not called,
>>>> it is not initialized when hitting the back button and tries to create
>>>> the tree using a null model.
>>>>
>>>> May the root problem has something to do with the "must-revalidate"
>>>> option? In the caching tutorial of wicket 1.5 it explicitly says
>>>> "We are not sending Cache-Control: must-revalidate anymore since it
>>>> implies the resource can theoretically be cached when in fact it must
>>>> not."
>>>> If this is the problem, is there some workaround to obtain the same
>>>> result as with the "must-revalidate" option?
>>>>
>>>>
>>>> Any advice or hint will be appreciated, and thank you very much for
>>>> your attention.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>
>> --
>> http://jetwick.com open twitter search
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>


-- 
http://jetwick.com open twitter search


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to