What would the nice replacement for:
@Override
public void onAttach() {
super.onAttach();
getForm().setDefaultButton(this);
}
be?
It leaves me in the same problem for:
http://www.nabble.com/forum/ViewPost.jtp?post=12981244&framed=y
I don't think anybody answered the question about
Component.checkHierarchyChange(final Component c)
I know I've been a pain in the **** but I'm just trying not to stick my
customer with a custom version of Wicket or something with a short shelf
life.
Johan Compagner wrote:
>
> as long as we have the page.onAttach() that is called when it is called
> from
> a session
> (as it is now) then it is fine by me
>
>
> On 10/7/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
>>
>> Also this would mean preserving page.onAttach, which would be the
>> first method called after page is taken from session, so that if user
>> need this event, they would get it (from there they can even cascade
>> it to other components, but we wouldn't do it by default).
>>
>> -Matej
>>
>> On 10/7/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
>> > Hi,
>> >
>> > what good is the onAttach method? We shouldn't encourage users
>> > initializing data upfront, as they should do it lazily on first
>> > demand. Attaching is also unreliable as when first time the page is
>> > attached, components inside repeaters aren't even built yet.
>> >
>> > So I think we should remove onAttach while we can. The benefit would
>> > be that the code would get less bloated and we'd also save quite a few
>> > traversals (look at MarkupContainer.internalAttach2(). Looks rather
>> > scary).
>> >
>> > -Matej
>> >
>>
>
>
--
View this message in context:
http://www.nabble.com/Remove-%28on%29attach--tf4583596.html#a13092729
Sent from the Wicket - Dev mailing list archive at Nabble.com.
