|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
|
|
checkHierarchyChangeHi,
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: checkHierarchyChangethe 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 <juergen.donnerstag@...> 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: checkHierarchyChangeTake 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 <matej.knopp@...> 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 > <juergen.donnerstag@...> 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: checkHierarchyChangein 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 <juergen.donnerstag@...> 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 <matej.knopp@...> 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 >> <juergen.donnerstag@...> 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: checkHierarchyChangeDoes 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 <igor.vaynberg@...> 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 > <juergen.donnerstag@...> 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 <matej.knopp@...> 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 >>> <juergen.donnerstag@...> 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: checkHierarchyChangeit 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 <juergen.donnerstag@...> 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 <igor.vaynberg@...> 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 >> <juergen.donnerstag@...> 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 <matej.knopp@...> 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 >>>> <juergen.donnerstag@...> 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 >>>>> >>>> >>> >> > |
| Free embeddable forum powered by Nabble | Forum Help |