> public DerivedPage extends BasePage {
>
> private String name;
>
> public DerivedPage(String name) {
> super();
> this.name = name;
> }
>
> public abstract addAbstract1(String abstractId1) {
> add(new NamePanel(abstractId1, name));
> }
> }
>
> This code is broken, since you're constructing NamePanel before name
has
> been initialized. Someone later in this thread shows a better way to
do
> this, by calling the overridable methods from onBeforeRender. But this
> is also tricky; because onBeforeRender can be called multiple times
you
> must maintain a flag to ensure you only add your panels once.
>
> Given these subtle problems with this approach, I admit I'm warming to
> the multiple extend/child idea.
Good to hear!! Multiple abstract/implements (child/extends) lets us
avoid the ugly plumbing code suggested in previous posts as an
alternative. I'd rather extend an elegant existing feature with
multiplicity than have to add low level plumbing code to my apps that
assumes a knowledge of the lifecycle methods (eg., onBeforeRender -
never needed to override that method for anything else before now) and
requires me to hook in to the lifecycle at various obscure places like
suggested. I think this goes against the wicket's simplicity motto way
more than supporting multiple child/extends sections does.
The beauty of the multiple extend/child idea is that it's not a
completely new concept we're talking about here - it's merely an issue
of supporting n>1 instead of arbitrarily fixing n=1 like it is now.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
