this is already fixed in the branch that will be 1.3.6

-igor

On Tue, Feb 10, 2009 at 8:53 AM, Michael O'Cleirigh
<[email protected]> wrote:
> Hello,
>
> I am using wicket 1.3.5.
>
> I control the visibility of my component hierarchy by overriding
> Component.onBeforeRender() and calling the
> Component.setVisibilityAllowed(..) as required for each sub component/panel.
>
> I've been having a performance problem that I've tracked to the
> Component.onBeforeRender() method being called on my entire component
> hierarchy regardless of the defined Component.isVisibilityAllowed() context.
>  i.e. I would have expected that if the parent
> Component.isVisibilityAllowed() returns false that none of the child
> components onBeforeRender() method's would need to be called.
>
> In Component.render(markupStream) it calls Component.determineVisibility()
> which delegates to isVisibilityAllowed() and applies my visibility
> preference during the rendering of the component.
>
> However in Component.internalBeforeRender() (see below) the execution of
> onBeforeRender() is controlled by isVisible() which skips my visibility
> context:
>
> private final void internalBeforeRender()
>   {
>       if ((isVisible() || callOnBeforeRenderIfNotVisible()) &&
> !getFlag(FLAG_RENDERING) &&
>           !getFlag(FLAG_PREPARED_FOR_RENDER))
>       {
>           setFlag(FLAG_BEFORE_RENDERING_SUPER_CALL_VERIFIED, false);
>
>           onBeforeRender();
>           getApplication().notifyComponentOnBeforeRenderListeners(this);
>           if (!getFlag(FLAG_BEFORE_RENDERING_SUPER_CALL_VERIFIED))
>           {
>               throw new IllegalStateException(Component.class.getName() +
>                   " has not been properly rendered. Something in the
> hierarchy of " +
>                   getClass().getName() +
>                   " has not called super.onBeforeRender() in the override of
> onBeforeRender() method");
>           }
>       }
>   }
>
> I was able to switch all my calls from setVisibilityAllowed() to
> setVisible() using eclipse refactoring to get the behavior/performance I
> need but am still wondering if this is how Component.setVisibilityAllowed()
> is supposed to work?
>
> Regards,
>
> Mike
>
>
>
>

Reply via email to