I dont think we can get rid of it all. We need checking because what if i do this
MyModelInnerClassPageA model = new MyModelInnerClassPageA() PageB b = new PageB(model) This is ofcourse a simple example but there are all kind of variants. So if we remove it and dont log big warnings/errors this could result in way more strange results... On 03/03/2009, Matej Knopp <[email protected]> wrote: > The problem of course are explicit page references. Actually, it is > the code in wicket that makes it possible to use page references. It's > *huge* pain to maintain and it still doesn't work flawlessly (and > never will). Anonymous classes are only tip of iceberg. > > Also, if we get rid of all the magic code, anonymous references will > work. Because they will be normally serialized with the outermost > page. It will not be ideal performance wise and it's a bad practice, > but it will not cause stack overflow. > > -Matej > > On Tue, Mar 3, 2009 at 12:01 AM, Martijn Dashorst > <[email protected]> wrote: >> The problem is not IMO the page reference that gets passed in >> explicitly, but those anonymous references to the surrounding >> page/component that are the cause of subtle bugs. The problem is that >> you won't get rid of those references with this solution... >> >> Martijn >> >> On Mon, Mar 2, 2009 at 11:38 PM, Matej Knopp <[email protected]> >> wrote: >>> Hi, >>> >>> more perceptive people have probably noticed that there is some really >>> obscure page serialization related code in Wicket. What it is supposed >>> to do is to make sure that when PageA holds reference to pageB, pageA >>> and pageB get serialized separately and when pageA is deserialized, >>> pageB is loaded also separately. So that the two pages would not be >>> serialized in one piece. >>> >>> Unfortunately this is not as simple as it sounds, because pageB can >>> hold reference to pageC which in turn can have an object that is >>> anonymous class from pageA, so we need to deal with circular >>> references, implicit references and lot of other nasty things. The >>> bottom line is, this causes many weird serialization related bugs that >>> are extremely difficult to fix. The code is also big pain to maintain. >>> >>> Simply put, passing references between pages and page serialization >>> don't mix nicely. We need page serialization because it really helps >>> scalability and memory consumption so I think it might be time to >>> "deprecate" page references. >>> >>> Of course there would be a simple alternative. >>> >>> I.e. instead of >>> >>> class PageA ... >>> { >>> ... >>> public void doSomething() { >>> setResponsePage(new PageB(this)); >>> } >>> } >>> >>> it would be >>> >>> class PageA ... >>> { >>> ... >>> public void doSomething() { >>> setResponsePage(new PageB(this.getReference())); >>> } >>> } >>> >>> and >>> >>> class PageB ... >>> { >>> public PageB(final PageReference<PageA> pageA) >>> { >>> // to get the actual instance if you need it >>> PageA a = pageA.get(); >>> >>> // or use the reference directly >>> add(new PageLink("back", pageA); >>> >>> // or even like this >>> add(new Link("back2") { public void onClick() { >>> getRequestCycle().setResponsePage(pageA) } }); >>> } >>> } >>> >>> Also this would help the performance, because if PageB only uses pageA >>> to return back (which is IMHO the most common case) it would only >>> require tiny PageReference object instead of entire page. >>> >>> -Matej >>> >> >> >> >> -- >> Become a Wicket expert, learn from the best: http://wicketinaction.com >> Apache Wicket 1.3.5 is released >> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. >> >
