that looks the best to me add the getPageReference() in 1.4 so people are going to play with it and add a warning in the current code (that should be really simple and point to the getPageReference())
Because if we remove it from 1.4 now when it is already RC this would mean some breaks that are not api or compile error breaks no to test if you are ok you have to walk over your complete solution! And see if you get an error/warning somewhere in your log This means way more testing for anybody moving to 1.4 to get 1.5 generics for big solutions (for example for martijn this would mean loads of clicks to test Vocus.....) johan On Tue, Mar 3, 2009 at 10:39, Matej Knopp <[email protected]> wrote: > I talked to Johan and he seems to feel quite strongly against removing > the code. So we can add PageReference, add warning when serializing > "nested" pages with message how to fix it (use page reference). And > the magic code will be gone in 1.5. > > -Matej > - Show quoted text - > > On Tue, Mar 3, 2009 at 8:29 AM, Johan Compagner <[email protected]> > wrote: > > 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. > >>> > >> > > >
