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