checkHierarchyChange

[Juergen Donnerstag <ju...@gmail.com>]

Hi,

question to the experts: If called during the render phase
Component.setVisible() will throw an exception saying "Cannot modify
component hierarchy after render phase has started (page version cant
change then anymore)");

That is because Component.setVisible() ->
Page.componentStateChanging(..) ->
versionManager.componentStateChanging(change), with
SecondLevelCachePageVersionManager being the default version manager
implementation. Its implementation of componentStateChanging() however
is empty. Thus it should actually be possible to make that change
during the render phase, correct?

Is there anything I'm missing here?

Thanks for your help
Juergen

Re: checkHierarchyChange

[Igor Vaynberg <ig...@gmail.com>]

it may be safe in case of enclosure handler but i would like to keep
the check there. the thing is that autocomponents are rendered at
runtime, so the user will have to know to manually call before render
and after render on them, etc.

-igor

On Fri, Sep 25, 2009 at 1:54 PM, Juergen Donnerstag
<ju...@gmail.com> wrote:
> Does it mean I can savely remove isAuto() check and throwing the
> exception in checkHierarchyChange?
>
> -Juergen
>
> On Fri, Sep 25, 2009 at 6:19 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> in case of enclosure none of the inconsistencies matej spoke off will
>> be applicable because enclosure sets visibility only on component that
>> are its direct children, so none of them have been rendered before the
>> visibilty change. it also restores the visibility after the render is
>> done.
>>
>> this was mostly to appease the added-but-not-rendered debug check we
>> have. if we didnt have that then the enclosure can simply skip its tag
>> when not visible.
>>
>> -igor
>>
>> On Fri, Sep 25, 2009 at 6:31 AM, Juergen Donnerstag
>> <ju...@gmail.com> wrote:
>>> Take a look at Enclosure.java. Enclosure instances are created when
>>> <wicket:enclosure> tag are detected in the markup during the render
>>> phase. Enclosure.onComponentTag() than uses the "child"'s visibilty to
>>> determine the enclosures visibility. But that of the body; the tag
>>> <wicket:enclosure> should always be rendered. Thus moving the
>>> visibility logic into onBeforeRender doesn't work either.
>>>
>>> It works today because we have so called auto-components which are
>>> ignored for hierarchy checks. I'm currently working on using
>>> IMarkupFragments for the render process and wanted to remove this
>>> whole auto-component stuff. This is when I came across the hierarchy
>>> check.
>>>
>>> Juergen
>>>
>>> On Fri, Sep 25, 2009 at 2:19 PM, Matej Knopp <ma...@gmail.com> wrote:
>>>> the entire state change thing is bit out dated.
>>>> Why do you need to change visibility during render? I think the
>>>> problem here is possible inconsistency. If you hide component before
>>>> it has been rendered it will not render. But if you hide it after
>>>> nothing will change.
>>>>
>>>> -Matej
>>>>
>>>> On Thu, Sep 24, 2009 at 11:36 PM, Juergen Donnerstag
>>>> <ju...@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> question to the experts: If called during the render phase
>>>>> Component.setVisible() will throw an exception saying "Cannot modify
>>>>> component hierarchy after render phase has started (page version cant
>>>>> change then anymore)");
>>>>>
>>>>> That is because Component.setVisible() ->
>>>>> Page.componentStateChanging(..) ->
>>>>> versionManager.componentStateChanging(change), with
>>>>> SecondLevelCachePageVersionManager being the default version manager
>>>>> implementation. Its implementation of componentStateChanging() however
>>>>> is empty. Thus it should actually be possible to make that change
>>>>> during the render phase, correct?
>>>>>
>>>>> Is there anything I'm missing here?
>>>>>
>>>>> Thanks for your help
>>>>> Juergen
>>>>>
>>>>
>>>
>>
>

Re: checkHierarchyChange

[Juergen Donnerstag <ju...@gmail.com>]

Does it mean I can savely remove isAuto() check and throwing the
exception in checkHierarchyChange?

-Juergen

On Fri, Sep 25, 2009 at 6:19 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> in case of enclosure none of the inconsistencies matej spoke off will
> be applicable because enclosure sets visibility only on component that
> are its direct children, so none of them have been rendered before the
> visibilty change. it also restores the visibility after the render is
> done.
>
> this was mostly to appease the added-but-not-rendered debug check we
> have. if we didnt have that then the enclosure can simply skip its tag
> when not visible.
>
> -igor
>
> On Fri, Sep 25, 2009 at 6:31 AM, Juergen Donnerstag
> <ju...@gmail.com> wrote:
>> Take a look at Enclosure.java. Enclosure instances are created when
>> <wicket:enclosure> tag are detected in the markup during the render
>> phase. Enclosure.onComponentTag() than uses the "child"'s visibilty to
>> determine the enclosures visibility. But that of the body; the tag
>> <wicket:enclosure> should always be rendered. Thus moving the
>> visibility logic into onBeforeRender doesn't work either.
>>
>> It works today because we have so called auto-components which are
>> ignored for hierarchy checks. I'm currently working on using
>> IMarkupFragments for the render process and wanted to remove this
>> whole auto-component stuff. This is when I came across the hierarchy
>> check.
>>
>> Juergen
>>
>> On Fri, Sep 25, 2009 at 2:19 PM, Matej Knopp <ma...@gmail.com> wrote:
>>> the entire state change thing is bit out dated.
>>> Why do you need to change visibility during render? I think the
>>> problem here is possible inconsistency. If you hide component before
>>> it has been rendered it will not render. But if you hide it after
>>> nothing will change.
>>>
>>> -Matej
>>>
>>> On Thu, Sep 24, 2009 at 11:36 PM, Juergen Donnerstag
>>> <ju...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> question to the experts: If called during the render phase
>>>> Component.setVisible() will throw an exception saying "Cannot modify
>>>> component hierarchy after render phase has started (page version cant
>>>> change then anymore)");
>>>>
>>>> That is because Component.setVisible() ->
>>>> Page.componentStateChanging(..) ->
>>>> versionManager.componentStateChanging(change), with
>>>> SecondLevelCachePageVersionManager being the default version manager
>>>> implementation. Its implementation of componentStateChanging() however
>>>> is empty. Thus it should actually be possible to make that change
>>>> during the render phase, correct?
>>>>
>>>> Is there anything I'm missing here?
>>>>
>>>> Thanks for your help
>>>> Juergen
>>>>
>>>
>>
>

Re: checkHierarchyChange

[Igor Vaynberg <ig...@gmail.com>]

in case of enclosure none of the inconsistencies matej spoke off will
be applicable because enclosure sets visibility only on component that
are its direct children, so none of them have been rendered before the
visibilty change. it also restores the visibility after the render is
done.

this was mostly to appease the added-but-not-rendered debug check we
have. if we didnt have that then the enclosure can simply skip its tag
when not visible.

-igor

On Fri, Sep 25, 2009 at 6:31 AM, Juergen Donnerstag
<ju...@gmail.com> wrote:
> Take a look at Enclosure.java. Enclosure instances are created when
> <wicket:enclosure> tag are detected in the markup during the render
> phase. Enclosure.onComponentTag() than uses the "child"'s visibilty to
> determine the enclosures visibility. But that of the body; the tag
> <wicket:enclosure> should always be rendered. Thus moving the
> visibility logic into onBeforeRender doesn't work either.
>
> It works today because we have so called auto-components which are
> ignored for hierarchy checks. I'm currently working on using
> IMarkupFragments for the render process and wanted to remove this
> whole auto-component stuff. This is when I came across the hierarchy
> check.
>
> Juergen
>
> On Fri, Sep 25, 2009 at 2:19 PM, Matej Knopp <ma...@gmail.com> wrote:
>> the entire state change thing is bit out dated.
>> Why do you need to change visibility during render? I think the
>> problem here is possible inconsistency. If you hide component before
>> it has been rendered it will not render. But if you hide it after
>> nothing will change.
>>
>> -Matej
>>
>> On Thu, Sep 24, 2009 at 11:36 PM, Juergen Donnerstag
>> <ju...@gmail.com> wrote:
>>> Hi,
>>>
>>> question to the experts: If called during the render phase
>>> Component.setVisible() will throw an exception saying "Cannot modify
>>> component hierarchy after render phase has started (page version cant
>>> change then anymore)");
>>>
>>> That is because Component.setVisible() ->
>>> Page.componentStateChanging(..) ->
>>> versionManager.componentStateChanging(change), with
>>> SecondLevelCachePageVersionManager being the default version manager
>>> implementation. Its implementation of componentStateChanging() however
>>> is empty. Thus it should actually be possible to make that change
>>> during the render phase, correct?
>>>
>>> Is there anything I'm missing here?
>>>
>>> Thanks for your help
>>> Juergen
>>>
>>
>

Re: checkHierarchyChange

[Juergen Donnerstag <ju...@gmail.com>]

Take a look at Enclosure.java. Enclosure instances are created when
<wicket:enclosure> tag are detected in the markup during the render
phase. Enclosure.onComponentTag() than uses the "child"'s visibilty to
determine the enclosures visibility. But that of the body; the tag
<wicket:enclosure> should always be rendered. Thus moving the
visibility logic into onBeforeRender doesn't work either.

It works today because we have so called auto-components which are
ignored for hierarchy checks. I'm currently working on using
IMarkupFragments for the render process and wanted to remove this
whole auto-component stuff. This is when I came across the hierarchy
check.

Juergen

On Fri, Sep 25, 2009 at 2:19 PM, Matej Knopp <ma...@gmail.com> wrote:
> the entire state change thing is bit out dated.
> Why do you need to change visibility during render? I think the
> problem here is possible inconsistency. If you hide component before
> it has been rendered it will not render. But if you hide it after
> nothing will change.
>
> -Matej
>
> On Thu, Sep 24, 2009 at 11:36 PM, Juergen Donnerstag
> <ju...@gmail.com> wrote:
>> Hi,
>>
>> question to the experts: If called during the render phase
>> Component.setVisible() will throw an exception saying "Cannot modify
>> component hierarchy after render phase has started (page version cant
>> change then anymore)");
>>
>> That is because Component.setVisible() ->
>> Page.componentStateChanging(..) ->
>> versionManager.componentStateChanging(change), with
>> SecondLevelCachePageVersionManager being the default version manager
>> implementation. Its implementation of componentStateChanging() however
>> is empty. Thus it should actually be possible to make that change
>> during the render phase, correct?
>>
>> Is there anything I'm missing here?
>>
>> Thanks for your help
>> Juergen
>>
>

Re: checkHierarchyChange

[Matej Knopp <ma...@gmail.com>]

the entire state change thing is bit out dated.
Why do you need to change visibility during render? I think the
problem here is possible inconsistency. If you hide component before
it has been rendered it will not render. But if you hide it after
nothing will change.

-Matej

On Thu, Sep 24, 2009 at 11:36 PM, Juergen Donnerstag
<ju...@gmail.com> wrote:
> Hi,
>
> question to the experts: If called during the render phase
> Component.setVisible() will throw an exception saying "Cannot modify
> component hierarchy after render phase has started (page version cant
> change then anymore)");
>
> That is because Component.setVisible() ->
> Page.componentStateChanging(..) ->
> versionManager.componentStateChanging(change), with
> SecondLevelCachePageVersionManager being the default version manager
> implementation. Its implementation of componentStateChanging() however
> is empty. Thus it should actually be possible to make that change
> during the render phase, correct?
>
> Is there anything I'm missing here?
>
> Thanks for your help
> Juergen
>