Hello, Peter and Martin, thank you very much for your feedback. Martin, you are right, I want that the page constructors are called everytime a page is loaded in the browser. I followed your instructions (I use org.apache.wicket.request.http.WebResponse.disableCaching() , and my pages are bookmarkable according to the "Page.isBookmarkable()" function), yet the problem persists.
After some tests, it seems to have something to do with the special version parameter in the URL you mentioned. I'll explain it through an example: 1- I enter the page through a link; it works perfectly. Its version is 8. http://localhost:8080/projects_show?8&toShow=4 2- I follow a link in this page to another one, and there is no problem. This page version is 9. http://localhost:8080/project_show?9&toShow=4&pj=103 3 - I hit the back button to the "projects_show" page, and then it crash (and the page constructor is not called). The page version is 8 http://localhost:8080/projects_show?8&toShow=4 4 - If I just copy the previous URL to another tab in the browser, it crashes and the page constructor is not called (same behaviour as in point 3). The page version is 8. 5 - If I copy the URL to another tab, but I change the special version parameter for another one which was not used yet (50, for instance), the page constructor is called, and the application works correctly. The page version is automatically updated to the next number in the sequence (in this case, 10). http://localhost:8080/projects_show?10&toShow=4 So, I think a workaround could be a "Just ignore the version parameter" option. Can you tell me if such an option exists in Wicket, or if you guess another workaround/solution for this issue? Again, thank you for your answers, and best regards. 2011/4/21 Peter Karich <[email protected]>: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
