You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by John Krasnay <jo...@krasnay.ca> on 2008/11/20 05:25:56 UTC

Feature idea: sealed flag on MarkupContainer

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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Feature idea: sealed flag on MarkupContainer

Posted by John Krasnay <jo...@krasnay.ca>.
On Thu, Nov 20, 2008 at 07:18:11PM +0100, Peter Ertl wrote:
> for SubPanel the ctor is called that order
> 
> - ....
> - Panel
> - BasePanel
      calls MarkupContainer.add()
          calls SubPanel.onComponentAdd() (before SubPanel ctor!)
> - 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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Feature idea: sealed flag on MarkupContainer

Posted by Peter Ertl <pe...@gmx.net>.
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: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Feature idea: sealed flag on MarkupContainer

Posted by John Krasnay <jo...@krasnay.ca>.
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: users-unsubscribe@wicket.apache.org
> >>>For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Feature idea: sealed flag on MarkupContainer

Posted by Peter Ertl <pe...@gmx.net>.
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: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Feature idea: sealed flag on MarkupContainer

Posted by John Krasnay <jo...@krasnay.ca>.
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: users-unsubscribe@wicket.apache.org
> >For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Feature idea: sealed flag on MarkupContainer

Posted by Peter Ertl <pe...@gmx.net>.
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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org