You should use PageReference (Page#getPageReference()). -- Jeremy Thomerson http://www.wickettraining.com
On Sun, May 16, 2010 at 11:52 PM, Rik van der Kleij <[email protected]>wrote: > Hi Jeremy, > > So an instance field inside a page that points to another page is also > something you should avoid? In our application we using this pattern a lot > (for going back to previous page) but it never seems to be any problem. So > probably because our pages don't consume a lot of memory. > > Regards, > Rik > > On 17 mei 2010, at 06:13, Jeremy Thomerson wrote: > > > In general, you should not pass references to components to other pages. > > That section on anonymous inner classes is telling you that when you > create > > an anonymous inner class and pass it to another page, you > > will inadvertently be passing a reference to the outer class, which is > > typically a page. This builds up memory and you will get a OOM. Passing > > models between pages is absolutely fine - as long as you're not > accidentally > > passing a bunch of other stuff with it (including large domain objects - > > which should be detached by using a detachable model). The page linked > to > > even says that you will often pass models between pages. > > > > -- > > Jeremy Thomerson > > http://www.wickettraining.com > > > > > > > > On Sun, May 16, 2010 at 11:05 PM, Rik van der Kleij < > [email protected]>wrote: > > > >> Hi Bernard and Mike, > >> > >> According to > >> > https://cwiki.apache.org/WICKET/best-practices-and-gotchas.html#BestPracticesandGotchas-AnonymousInnerclassessharingmodels > could eventually lead to Out of memory error. > >> > >> Holding a page reference in an instance field that points to another > page > >> looks the same but it is doesn't seems to be a problem. What's the > >> difference? > >> > >> Regards, > >> Rik > >> > >> > >> On 16 mei 2010, at 04:39, Michael O'Cleirigh wrote: > >> > >>> Hello, > >>> > >>> I'm not sure on the answer to your question about the anonymous inner > >> class but in general sharing models between pages can be a bad idea. > >>> > >>> The memory issues comes into play if the IModel is like Model and the > >> contained object is not transient (it is serialized as part of the > page). > >>> > >>> While Pages are serialized each page is serialized independently so on > >> page reload the IModel from the first page is no longer the same object > >> instance as the IModel from the second page. At deserialization time > the > >> page1.model.getObject().equals page2.model.getObject() but > >> page1.model.getObject() != page2.model.getObject(); so any changes to > either > >> model are not shared between then. > >>> > >>> This is not a problem if the model is loadable since the memory of the > >> page it is contained in doesn't matter as the value is loaded from the > >> backend db or some other independent data source like the httpsession, > or > >> with wicketApplication. > >>> > >>> You can see the same effect if you try and share a model between a > panel > >> and a ModelWindow that uses a PageCreator > >>> > >>> Hope this helps, > >>> > >>> Mike > >>>> Hi, > >>>> > >>>> Can someone explain me why it is a memory issue when an instance of an > >> anonymous IModel class is passed to another page to be shared, but it > seems > >> to be no problem when a page reference is passed to another page and is > put > >> in an instance field (for example to be used in a button to navigate > back to > >> previous page)? > >>>> > >>>> Many thanks. > >>>> > >>>> Regards, > >>>> Rik > >>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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] > >>> > >> > >> > >> --------------------------------------------------------------------- > >> 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] > >
