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
<martijn.dasho...@gmail.com> 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 <matej.kn...@gmail.com> 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.
>
