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 <peat...@yahoo.de> 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 < > ismael.hasan.rom...@gmail.com > >> 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: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > > -- > http://jetwick.com open twitter search > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: 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/>
