Hi,
On Fri, Feb 8, 2013 at 11:44 AM, Bernard <bht...@gmail.com> wrote: > Hi, > > This is what I like about Wiket. > > Even if I start with a stateless page! So I update a component, and > Wicket takes care of it via server side state - job done. > > The page is then no longer stateless which is fair. > > But: > > When the user stays on this page and the session expires, then even > simple Links on the page like a sign-out link that do NOT require > state cause PageExpiredException. In this case the beautiful > advantages of using Wicket are gone. Working around these issues can > be very expensive because one has to examine every single page in the > special session expiry scenario. The workaround code becomes very > ugly. > > Are there any plans to fix this or is this a feature? > This is by design. If Wicket cannot find the old page by any reason (e.g. expired session with all its pages) then depending on the value of IPageSettings#getRecreateMountedPagesAfterExpiry() Wicket may create a new instance for you. Now: 1) if the new instance is stateless then Wicket will execute the listener interface, i.e. will execute StatelessLink#onClick, StatelessForm#onSubmit, ... 2) if the newly created page is stateful Wicket will just render it *without* executing the listener interface Why ? Because the stateless link/form/behavior/... may or may not be in the page component tree. Wicket cannot make assumptions that the component/behavior exists in the page initial state (i.e. right after instantiating it). The link that your user has clicked on the expired page may have been added in state 2 of the page, and thus it is not available in state 1 (the initial state). Use case: - render a simple stateful page with just linkA and am empty panel - the user clicks on linkA which replaces the empty panel with a panel with linkB inside - later the user clicks on linkB - if the session is expired and Wicket creates a new instance of the page then linkB is not in the component tree. Only linkA and the empty panel are there. Once linkA is used linkB will appear, but Wicket cannot do this because it doesn't know what to do to get linkB and execute its onClick() method I'll add this explanation to a FAQ section at http://martin-g.github.com/wicket-reference-guide/stateless.html . If we change this behavior and try to execute the listener interface then it will work when linkB is in the initial state and will throw ComponentNotFoundException when linkB is added to the tree after some interaction. So it will become nondeterministic - a russian roulette. I'll take a look at your new tickets once I have more time > > Bernard > > > > On Fri, 8 Feb 2013 09:09:34 +0100, you wrote: > > >Hi, > > > >It is OK. > >But you can also just update some field/model in the current page > instance. > > > > > >On Fri, Feb 8, 2013 at 7:00 AM, snair <sreelatha.n...@transport.wa.gov.au > >wrote: > > > >> Is it ok to call the same page using setResponsePage(), only calling a > >> different constructor, since the page now needs to display additional > >> information, which I will be passing into this new constructor? For > >> example, from PageA, can I say setResponsePage(new PageA(String a)) > when a > >> submit button button is clicked. > >> > >> > >> > >> -- > >> View this message in context: > >> > http://apache-wicket.1842946.n4.nabble.com/call-the-same-page-using-setResponsePage-tp4656192.html > >> Sent from the Users forum mailing list archive at Nabble.com. > >> > >> --------------------------------------------------------------------- > >> 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 <http://jweekend.com/>
