Re: Best practises question
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.comwrote: 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.comwrote: 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
Re: Best practises question
It's just a matter of understanding how anonymous inner classes (or named inner classes) work. It's not a Wicket thing. It's a Java thing. So, if it's confusing, take it up with Oracle. On Tue, May 18, 2010 at 3:05 AM, Rik van der Kleij rikvdkl...@gmail.com wrote: 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.comwrote: 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.comwrote: 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
Re: Best practises question
No, that is not what I mention. The point is that the Best practise has to be: Do not share Wicket components between pages. Regards, Rik On 18 mei 2010, at 12:37, James Carman wrote: It's just a matter of understanding how anonymous inner classes (or named inner classes) work. It's not a Wicket thing. It's a Java thing. So, if it's confusing, take it up with Oracle. On Tue, May 18, 2010 at 3:05 AM, Rik van der Kleij rikvdkl...@gmail.com wrote: 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.comwrote: 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.comwrote: 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:
Re: Best practises question
Well, I think that's quite obvious when you consider that each page is the root of a tree (not directed, acyclic graph) of components. Each component can have at most one parent. On Tue, May 18, 2010 at 6:54 AM, Rik van der Kleij rikvdkl...@gmail.com wrote: No, that is not what I mention. The point is that the Best practise has to be: Do not share Wicket components between pages. Regards, Rik On 18 mei 2010, at 12:37, James Carman wrote: It's just a matter of understanding how anonymous inner classes (or named inner classes) work. It's not a Wicket thing. It's a Java thing. So, if it's confusing, take it up with Oracle. On Tue, May 18, 2010 at 3:05 AM, Rik van der Kleij rikvdkl...@gmail.com wrote: 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.comwrote: 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.comwrote: 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:
SV: Best practises question
Well, I think that's quite obvious when you consider that each page is the root of a tree (not directed, acyclic graph) of components. Each component can have at most one parent. But you can pass a component to a different page/component without adding it; like in the example of having a back link which wants a page to navigate back to. If you keep that Page in an instance variable in the back-from Page you will needlessly serialize that, too, unless you use a PageReference. - Tor Iver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best practises question
Perhaps during development mode there should be a warning message if Wicket sees any fields on any components that are of type Page (or a subclass thereof)? Or, even if the actual object is a page (the variable type could be some interface), it should spit out a warning telling you to use PageReference instead? On Tue, May 18, 2010 at 8:37 AM, Wilhelmsen Tor Iver toriv...@arrive.no wrote: Well, I think that's quite obvious when you consider that each page is the root of a tree (not directed, acyclic graph) of components. Each component can have at most one parent. But you can pass a component to a different page/component without adding it; like in the example of having a back link which wants a page to navigate back to. If you keep that Page in an instance variable in the back-from Page you will needlessly serialize that, too, unless you use a PageReference. - Tor Iver - 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
Re: Best practises question
It might even be interesting to have warnings like this as pluggable runtime libraries that users could download from wicket-stuff. The idea is if a developer downloads and installs some of the libraries on their instance, they would get additional debugging output, and because they are in wicket-stuff, there's more opportunity for community participation. Maybe there's an SPI that uses AOP for the libraries to plug in with. It's kind of like running 'lint' on the C compilers of yore, but with metadata-driven plugins that would be easy to share. I bring it up because a client project I am working on has this problem all over the place. It was something I knew had a solution, but along with a hundred other worst practices, it doesn't get solved quickly unless I happen to get hit over the head with the answer in a forum like this or while surfing. Installing a wicket lint superbundle would have given me a great log of problems and solutions, making both this app and the world of wicket apps that much more robust and appealing to new candidates. Brian On May 18, 2010, at 9:44 AM, James Carman wrote: Perhaps during development mode there should be a warning message if Wicket sees any fields on any components that are of type Page (or a subclass thereof)? Or, even if the actual object is a page (the variable type could be some interface), it should spit out a warning telling you to use PageReference instead? On Tue, May 18, 2010 at 8:37 AM, Wilhelmsen Tor Iver toriv...@arrive.no wrote: Well, I think that's quite obvious when you consider that each page is the root of a tree (not directed, acyclic graph) of components. Each component can have at most one parent. But you can pass a component to a different page/component without adding it; like in the example of having a back link which wants a page to navigate back to. If you keep that Page in an instance variable in the back-from Page you will needlessly serialize that, too, unless you use a PageReference. - Tor Iver - 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
Re: Best practises question
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.comwrote: 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.comwrote: 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
Re: Best practises question
Are there any patterns described how to use PageReference efficiently? Žilvinas Vilutis Mobile: (+370) 652 38353 E-mail: cika...@gmail.com On Mon, May 17, 2010 at 9:55 AM, Jeremy Thomerson jer...@wickettraining.com 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.comwrote: Hi Bernard and Mike, According to https://cwiki.apache.org/WICKET/best-practices-and-gotchas.html#BestPracticesandGotchas-AnonymousInnerclassessharingmodelscould 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
Re: Best practises question
Not that I know of. Although googling Wicket pagereference will give you a discussion thread on it. Basically, just replace private Page previousPage with private PageReference previousPage. -- Jeremy Thomerson http://www.wickettraining.com On Mon, May 17, 2010 at 12:35 PM, Zilvinas Vilutis cika...@gmail.comwrote: Are there any patterns described how to use PageReference efficiently? Žilvinas Vilutis Mobile: (+370) 652 38353 E-mail: cika...@gmail.com On Mon, May 17, 2010 at 9:55 AM, Jeremy Thomerson jer...@wickettraining.com 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.comwrote: Hi Bernard and Mike, According to https://cwiki.apache.org/WICKET/best-practices-and-gotchas.html#BestPracticesandGotchas-AnonymousInnerclassessharingmodelscouldeventually 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
Re: Best practises question
Page someBigPage = new YourBigPage(...); PageReference bigPageRef = someBigPage.getPageReference(); Now you just keep a hold of bigPageRef. When you want to go back to that page you just ask it for the page: Page reconstitutedBigPage = bigPageRef.getPage(); On Mon, May 17, 2010 at 10:35 AM, Zilvinas Vilutis cika...@gmail.com wrote: Are there any patterns described how to use PageReference efficiently? Žilvinas Vilutis Mobile: (+370) 652 38353 E-mail: cika...@gmail.com On Mon, May 17, 2010 at 9:55 AM, Jeremy Thomerson jer...@wickettraining.com 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.comwrote: Hi Bernard and Mike, According to https://cwiki.apache.org/WICKET/best-practices-and-gotchas.html#BestPracticesandGotchas-AnonymousInnerclassessharingmodelscould 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,
Re: Best practises question
Hi Bernard and Mike, According to https://cwiki.apache.org/WICKET/best-practices-and-gotchas.html#BestPracticesandGotchas-AnonymousInnerclasses sharing models 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
Re: Best practises question
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.comwrote: Hi Bernard and Mike, According to https://cwiki.apache.org/WICKET/best-practices-and-gotchas.html#BestPracticesandGotchas-AnonymousInnerclassessharing models 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
Re: Best practises question
Speaking of performance, my pages are using quite a bunch of technologies and session size varies ~30-40 KB, sometimes it raises to 80-90 KB. Is that a considerable amount? Previously I've been working with JSF where session size was 2-6 MB - so comparing to that it seems to be almost zero :) But is this normal amount for wicket pages? Thank you Žilvinas Vilutis Mobile: (+370) 652 38353 E-mail: cika...@gmail.com On Sun, May 16, 2010 at 9:13 PM, Jeremy Thomerson jer...@wickettraining.com 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
Re: Best practises question
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.comwrote: Hi Bernard and Mike, According to https://cwiki.apache.org/WICKET/best-practices-and-gotchas.html#BestPracticesandGotchas-AnonymousInnerclassessharing models 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
Best practises question
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
Re: Best practises question
Hi, Where is it said that passing IModel is an issue? It could be an issue if it is not a subclass of LoadableDetachableModel. Bernard On Sat, 15 May 2010 20:33:11 +0200, you wrote: 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
Re: Best practises question
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
