OK, suppose I _don't_ care about saving the model. I store it in the Page and
this time I want to re-create it from scratch (and reset components to their
defaults) every time the user re-enters the page. Do I have to make my
back-links bookmarkable, even though I don't really care whether the user can
bookmark my links? /Frank
-----Original Message-----
On Behalf Of Eelco Hillenius Wednesday, February 01, 2006 3:57 PM
> 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
NHµŠ²²u¦
º¦¢–Š~®z¶£¡…À^žz¶zjŠ¢¢•±Éºž{
,H4¶±²j‚þ
