To mine opinion this Best practise is confusing. It is just a matter of do not 
share Wicket components between pages because Wicket will not detect while 
serializing pages that components are already serialized. 

The case of sharing anonymous IModel implementations is a special case because 
implicitly a Wicket component is shared. So you have to be careful with sharing 
models.

Regards,
Rik



On 17 mei 2010, at 18:55, Jeremy Thomerson wrote:

> 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 
> <rikvdkl...@gmail.com>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 <
>> rikvdkl...@gmail.com>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: 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
>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> 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
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to