Sorry to hijack your discussion, I just want to say that even if you
keep the serialization magic, adding warning/ error logs when such
references are found, at least in the development configuration, would
be a big plus, because these references not only may cause problems in
wicket core code, they can lead to headaches anywhere.
Martin
2009/3/3 Johan Compagner <jcompag...@gmail.com>:
> 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 <matej.kn...@gmail.com> 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
>> <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.
>>>
>>
>
