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]
