> In Servlet technology we have the concept of request scope, page scope and > session scope. I would assume that Wicket object attributes all go into > session scope so that it's still there when a page is posted back – is that > correct?
That is correct in a sense but not relevant. The fact that Wicket stores pages in the session (which doesn't have to be in the actual HttpSession) should be seen as an implementation detail. As a programmer, you should think of this as Page scope (which really is a JSP inventation more than a Servlet thing btw). But you don't need to be concerned about it anyway: on a call back the page and its state should just be there for you. > Suppose I have an application in which users can go from page 1 to page 2 > and back again. There is some hard-to-compute model data in Page 1 that > needs re-computation _only_ if certain application-scope data was changed > while the user was on page 2. I don't want to re-compute the model if the > user never returns to page 1, nor if he returns to page 1 and the > application-scoped variable has the same value as before. Normally, you should have links that are implemented as callbacks (e.g. extending the Link class) and that active the other page either by holding references to the page and setting it as the current page to render, or that create a new page instance while passing a reference to that expensive model. Of course, that will make those page non-bookmarkable. The other option - in case you don't want to follow the above scenario/ want to make sure even the call to a bookmarkable page could reuse any previously created model data - is to store that model in the Session/ Application object. The disdvantage of this is of course that this will polute your session/ application and that it is not cleaned up until you specifically do so yourself. > Where in page 1 should I put the code to check the application-scope data > for changes and perhaps update the model data? What Wicket Page method > should I override? > For the second option I outlined above: the constructor. Eelco
