You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Marat Radchenko <sl...@gmail.com> on 2008/11/20 12:54:20 UTC

Extremely confisung onBeforeRender/callOnBeforeRenderIfNotVisible behavior

Hello, Wicket team and Wicket users.

We broke our mind this week while trying to understand onBeforeRender behavior.

Scenario #1:
Parent component A overrides onBeforeRender (and sets visibility
there) and returns true from callOnBeforeRenderIfNotVisible. Child
component B does the same. Then, onBeforeRender always happens on both
components regardless any of them is visible or not.
Good, but if A calculates isVisible = true then there it is impossible
for component B to become visible (well, actually B could set
visibility on A but this is very error-prone) so there's no point in
invoking onBeforeRender because B won't be rendered.

Scenario #2:
Parent component A overrides isVisible (and sets visibility there).
Child component B overrides isVisible too. Then B onBeforeRender will
be called only if A is visible and B is visible.
Good, no unnecessary job is done (B won't be processed at all when A
is not visible).

Scenario #3:
Parent component A overrides onBeforeRender and
callOnBeforeRenderIfNotVisible (and sets visibility there to FALSE).
Child B doesn't override callOnBeforeRenderIfNotVisible and doesn't
override isVisible. Then B's onBeforeRender will be called unless B is
not visible.

Scenario #4:
Parent component A overrides isVisible and doesn't use
callOnBeforeRenderIfNotVisible. Then, if it visible, all its children
are recursively processed, otherwise no before/after rendering happens
to them at all. Even if they override callOnBeforeRenderIfNotVisible.
That's first confusing point. Javadocs on
callOnBeforeRenderIfNotVisible promise us that onBeforeRender will be
called even if component is not visible, but it is a lie.
onBeforeRender will be called only if (component is visible OR
callOnBeforeRenderIfNotVisible returns true) AND onBeforeRender was
called on parent.

Thoughts:
1) Javadocs on callOnBeforeRenderIfNotVisible are wrong. See above,
there are conditions when onBeforeRender on B won't be called even if
it returns true from callOnBeforeRenderIfNotVisible.
2) Child behavior depends on parent's.
3) There is no way to set isVisible to FALSE in parent component and
avoid processing children (because Wicket requires calling
super.onBeforeRender which processes children). I'm thinking about a
feature request for this one.

This all seems to be very complicated & confusing. I hope my analisys
will help to invent better behavior.

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


Re: Extremely confisung onBeforeRender/callOnBeforeRenderIfNotVisible behavior

Posted by Marat Radchenko <sl...@gmail.com>.
Mistake in Scenario #1. Read as: Good, but if A calculates isVisible = _FALSE_

2008/11/20 Marat Radchenko <sl...@gmail.com>:
> Hello, Wicket team and Wicket users.
>
> We broke our mind this week while trying to understand onBeforeRender behavior.
>
> Scenario #1:
> Parent component A overrides onBeforeRender (and sets visibility
> there) and returns true from callOnBeforeRenderIfNotVisible. Child
> component B does the same. Then, onBeforeRender always happens on both
> components regardless any of them is visible or not.
> Good, but if A calculates isVisible = true then there it is impossible
> for component B to become visible (well, actually B could set
> visibility on A but this is very error-prone) so there's no point in
> invoking onBeforeRender because B won't be rendered.
>
> Scenario #2:
> Parent component A overrides isVisible (and sets visibility there).
> Child component B overrides isVisible too. Then B onBeforeRender will
> be called only if A is visible and B is visible.
> Good, no unnecessary job is done (B won't be processed at all when A
> is not visible).
>
> Scenario #3:
> Parent component A overrides onBeforeRender and
> callOnBeforeRenderIfNotVisible (and sets visibility there to FALSE).
> Child B doesn't override callOnBeforeRenderIfNotVisible and doesn't
> override isVisible. Then B's onBeforeRender will be called unless B is
> not visible.
>
> Scenario #4:
> Parent component A overrides isVisible and doesn't use
> callOnBeforeRenderIfNotVisible. Then, if it visible, all its children
> are recursively processed, otherwise no before/after rendering happens
> to them at all. Even if they override callOnBeforeRenderIfNotVisible.
> That's first confusing point. Javadocs on
> callOnBeforeRenderIfNotVisible promise us that onBeforeRender will be
> called even if component is not visible, but it is a lie.
> onBeforeRender will be called only if (component is visible OR
> callOnBeforeRenderIfNotVisible returns true) AND onBeforeRender was
> called on parent.
>
> Thoughts:
> 1) Javadocs on callOnBeforeRenderIfNotVisible are wrong. See above,
> there are conditions when onBeforeRender on B won't be called even if
> it returns true from callOnBeforeRenderIfNotVisible.
> 2) Child behavior depends on parent's.
> 3) There is no way to set isVisible to FALSE in parent component and
> avoid processing children (because Wicket requires calling
> super.onBeforeRender which processes children). I'm thinking about a
> feature request for this one.
>
> This all seems to be very complicated & confusing. I hope my analisys
> will help to invent better behavior.
>

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


Re: Extremely confisung onBeforeRender/callOnBeforeRenderIfNotVisible behavior

Posted by Marat Radchenko <sl...@gmail.com>.
That's bad because isVisible is invoked many times (50+ sometimes) per
request so no complex logic can be put there.

2008/11/20 Jeremy Thomerson <je...@wickettraining.com>:
> Like this?
>
> new YourComponent(id) {
>    @Override
>    public boolean isVisible() {
>        return yourCondition;
>    }
> }
>
> On Thu, Nov 20, 2008 at 9:33 AM, Marat Radchenko <
> slonopotamusorama@gmail.com> wrote:
>
>> So. Is there any recommended (and hopefully not error-prone) way of
>> handling conditional visibility?
>>
>> 2008/11/20 Matej Knopp <ma...@gmail.com>:
>>  >> That's first confusing point. Javadocs on
>> >> callOnBeforeRenderIfNotVisible promise us that onBeforeRender will be
>> >> called even if component is not visible, but it is a lie.
>> >
>> > Bad, bad javadoc!
>> >
>> > -Matej
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>

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


Re: Extremely confisung onBeforeRender/callOnBeforeRenderIfNotVisible behavior

Posted by Jeremy Thomerson <je...@wickettraining.com>.
Like this?

new YourComponent(id) {
    @Override
    public boolean isVisible() {
        return yourCondition;
    }
}

On Thu, Nov 20, 2008 at 9:33 AM, Marat Radchenko <
slonopotamusorama@gmail.com> wrote:

> So. Is there any recommended (and hopefully not error-prone) way of
> handling conditional visibility?
>
> 2008/11/20 Matej Knopp <ma...@gmail.com>:
>  >> That's first confusing point. Javadocs on
> >> callOnBeforeRenderIfNotVisible promise us that onBeforeRender will be
> >> called even if component is not visible, but it is a lie.
> >
> > Bad, bad javadoc!
> >
> > -Matej
> >
> > ---------------------------------------------------------------------
> > 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
>
>


-- 
Jeremy Thomerson
http://www.wickettraining.com

Re: Extremely confisung onBeforeRender/callOnBeforeRenderIfNotVisible behavior

Posted by Matej Knopp <ma...@gmail.com>.
private Boolean visible = null;

public boolean isVisible()
{
   if (visible == null)
  {
    visible = [ put your complicated logic here];
  }
  return visible;
}

public void onDetach()
{
  super.onDetach();
  visible = null;
}

What's wrong with this?

-Matej
On Thu, Nov 20, 2008 at 5:04 PM, Marat Radchenko
<sl...@gmail.com> wrote:
> I'm trying to choose strategy for handling conditional component
> visibility (and we have complex tree where many components are
> conditionally visible). Overriding isVisible is bad, because many
> calls. overriding onBeforeRender and callOnBeforeRender is bad,
> because children visibility is calculated even when there is no need.
> I'd prefer overriding onBeforeRender and skipping child traversion if
> isVisible = false, but that cannot be done with current
> Component#onBeforeRender implementation.
>
> 2008/11/20 Igor Vaynberg <ig...@gmail.com>:
>> you havent actually described your usecase yet...
>>
>> -igor
>>
>> On Thu, Nov 20, 2008 at 7:33 AM, Marat Radchenko
>> <sl...@gmail.com> wrote:
>>> So. Is there any recommended (and hopefully not error-prone) way of
>>> handling conditional visibility?
>>>
>>> 2008/11/20 Matej Knopp <ma...@gmail.com>:
>>>>> That's first confusing point. Javadocs on
>>>>> callOnBeforeRenderIfNotVisible promise us that onBeforeRender will be
>>>>> called even if component is not visible, but it is a lie.
>>>>
>>>> Bad, bad javadoc!
>>>>
>>>> -Matej
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: Extremely confisung onBeforeRender/callOnBeforeRenderIfNotVisible behavior

Posted by Igor Vaynberg <ig...@gmail.com>.
i still dont see a concrete usecase

-igor

On Thu, Nov 20, 2008 at 8:04 AM, Marat Radchenko
<sl...@gmail.com> wrote:
> I'm trying to choose strategy for handling conditional component
> visibility (and we have complex tree where many components are
> conditionally visible). Overriding isVisible is bad, because many
> calls. overriding onBeforeRender and callOnBeforeRender is bad,
> because children visibility is calculated even when there is no need.
> I'd prefer overriding onBeforeRender and skipping child traversion if
> isVisible = false, but that cannot be done with current
> Component#onBeforeRender implementation.
>
> 2008/11/20 Igor Vaynberg <ig...@gmail.com>:
>> you havent actually described your usecase yet...
>>
>> -igor
>>
>> On Thu, Nov 20, 2008 at 7:33 AM, Marat Radchenko
>> <sl...@gmail.com> wrote:
>>> So. Is there any recommended (and hopefully not error-prone) way of
>>> handling conditional visibility?
>>>
>>> 2008/11/20 Matej Knopp <ma...@gmail.com>:
>>>>> That's first confusing point. Javadocs on
>>>>> callOnBeforeRenderIfNotVisible promise us that onBeforeRender will be
>>>>> called even if component is not visible, but it is a lie.
>>>>
>>>> Bad, bad javadoc!
>>>>
>>>> -Matej
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: Extremely confisung onBeforeRender/callOnBeforeRenderIfNotVisible behavior

Posted by Marat Radchenko <sl...@gmail.com>.
I'm trying to choose strategy for handling conditional component
visibility (and we have complex tree where many components are
conditionally visible). Overriding isVisible is bad, because many
calls. overriding onBeforeRender and callOnBeforeRender is bad,
because children visibility is calculated even when there is no need.
I'd prefer overriding onBeforeRender and skipping child traversion if
isVisible = false, but that cannot be done with current
Component#onBeforeRender implementation.

2008/11/20 Igor Vaynberg <ig...@gmail.com>:
> you havent actually described your usecase yet...
>
> -igor
>
> On Thu, Nov 20, 2008 at 7:33 AM, Marat Radchenko
> <sl...@gmail.com> wrote:
>> So. Is there any recommended (and hopefully not error-prone) way of
>> handling conditional visibility?
>>
>> 2008/11/20 Matej Knopp <ma...@gmail.com>:
>>>> That's first confusing point. Javadocs on
>>>> callOnBeforeRenderIfNotVisible promise us that onBeforeRender will be
>>>> called even if component is not visible, but it is a lie.
>>>
>>> Bad, bad javadoc!
>>>
>>> -Matej
>>>
>>> ---------------------------------------------------------------------
>>> 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: Extremely confisung onBeforeRender/callOnBeforeRenderIfNotVisible behavior

Posted by Igor Vaynberg <ig...@gmail.com>.
you havent actually described your usecase yet...

-igor

On Thu, Nov 20, 2008 at 7:33 AM, Marat Radchenko
<sl...@gmail.com> wrote:
> So. Is there any recommended (and hopefully not error-prone) way of
> handling conditional visibility?
>
> 2008/11/20 Matej Knopp <ma...@gmail.com>:
>>> That's first confusing point. Javadocs on
>>> callOnBeforeRenderIfNotVisible promise us that onBeforeRender will be
>>> called even if component is not visible, but it is a lie.
>>
>> Bad, bad javadoc!
>>
>> -Matej
>>
>> ---------------------------------------------------------------------
>> 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: Extremely confisung onBeforeRender/callOnBeforeRenderIfNotVisible behavior

Posted by Marat Radchenko <sl...@gmail.com>.
So. Is there any recommended (and hopefully not error-prone) way of
handling conditional visibility?

2008/11/20 Matej Knopp <ma...@gmail.com>:
>> That's first confusing point. Javadocs on
>> callOnBeforeRenderIfNotVisible promise us that onBeforeRender will be
>> called even if component is not visible, but it is a lie.
>
> Bad, bad javadoc!
>
> -Matej
>
> ---------------------------------------------------------------------
> 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: Extremely confisung onBeforeRender/callOnBeforeRenderIfNotVisible behavior

Posted by Matej Knopp <ma...@gmail.com>.
> That's first confusing point. Javadocs on
> callOnBeforeRenderIfNotVisible promise us that onBeforeRender will be
> called even if component is not visible, but it is a lie.

Bad, bad javadoc!

-Matej

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