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
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
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
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
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
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
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
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
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()).
--
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
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,
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
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.
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
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.
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
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
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).
18 matches
Mail list logo
