for SubPanel the ctor is called that order

- ....
- Panel
- BasePanel
- SubPanel

so the fields will be initialized, eh?!


Am 20.11.2008 um 16:32 schrieb John Krasnay:

Here's the problem (also with sketchy pseudo code :)

public class BasePanel extends Panel {
   public BasePanel(String id) {
       super(id);
       add(new Label("foo", ...));
   }
}

public class SubPanel extends BasePanel {
   @Override
   public void onComponentAdd(Component child) {
       // oops, called from BasePanel ctor
       // my fields aren't initialized yet
   }
}

jk

On Thu, Nov 20, 2008 at 12:38:39PM +0100, Peter Ertl wrote:
I was thinking about something like this:

[warning, sketchy pseudo code will follow]

method org.apache.wicket.MarkupContainer.add(Component... children) :

  -> call empty overridable method onComponentAdd(Component child)
for each component
  -> add component

protected void onComponentAdd(Component child) { /* overridable */ }



Am 20.11.2008 um 12:30 schrieb John Krasnay:

Yeah, I thought about that. The problem is add() is usually called
from
a component's constructor, so you would have a case of a constructor
(indirectly) calling a non-final method,

jk

On Thu, Nov 20, 2008 at 11:27:39AM +0100, Peter Ertl wrote:
Wouldn't it be more powerful to override / hook into the process of
adding a component of a container?

Something like that ...

new WebMarkupContainer(id)
{
@Override
public void onComponentAdd(Component child)
{
 // check the sealed flag, decorate the child, throw exception, or
do [whatever]
}
}




Am 20.11.2008 um 05:25 schrieb John Krasnay:

Hi folks,

In my current Wicket app I have a panel that contains a vertically
stacked list of sub-panels. Because the precise list of sub-panels
is
not known until runtime, I've implemented this with a RepeatingView.
My
parent panel has the following methods that I use to build the
list of
sub-panels ("rv" is my RepeatingView instance):

public void addSubPanel(Panel subPanel) { rv.add(subPanel); }
public String newSubPanelId() { return rv.newChildId(); }

I use this same pattern in a number of other instances such as menus
and
button bars.

The problem is that I often mistakenly call add instead of
addSubPanel,
which of course fails at render time with an exception that I always
find hard to decipher.

It would be nice if there was a way to "seal" a MarkupContainer
once I
had populated it such that any subsequent call to add, remove, or
replace would fail immediately with an exception. This would make it
much easier to find out where I had made the mistake.

Does anyone else think this would be a worthwhile feature?

jk

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to