The second solution, building my own IRequestMapper worked, thank you very much for your help.
2011/4/26 Martin Grigorov <[email protected]>: > Use BookmarkablePageLink(MyPage.class, pageParameters) instead of Link > {onClick()} to go the page. > Try to make your page stateless (by using just stateless components). > > Or roll your own IRequestMapper which will always instantiate a new > page instance when your conditions are met, e.g. the request path is > "project_show". > > On Tue, Apr 26, 2011 at 1:29 PM, Ismael Hasan > <[email protected]> wrote: >> 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] >> >> > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com > > --------------------------------------------------------------------- > 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]
