But neither order is going to work. The problem is that the check should
not be on any component state, but on a global phase, probably held in the
request cycle (which already know what phase that is, somewhere in there).
I personally think you're right that a component is not attached until it
has attached its children. And we should definitely leave the component
state changes I made in place. We just need to do that check based on
something outside the component hierarchy. Since Page is not a reliable
place to put that because components may not have a Page yet, it seems like
RequestCycle would be the right place. After all, this IS the phase of the
request cycle.
Jonathan Locke wrote:
>
>
> actually, this is how i had it before almaw told me that would break
> everything.
>
>
> Johan Compagner wrote:
>>
>> ok we really need to fix this because this is broken now
>>
>> what i can do is in attach() this:
>>
>> setFlag(FLAG_ATTACHED, true);
>> attachChildren();
>>
>> swap:
>> attachChildren();
>> setFlag(FLAG_ATTACHED, true);
>>
>> (i think we should do this anyway)
>>
>> and then in checkForHierarchy()
>>
>> if (!isAttached())
>> {
>> throw new WicketRuntimeException(
>> "Cannot modify component unattached components");
>> }
>>
>> so test for is it attached()
>> that sounds logical
>>
>> except one problem in the constructor currently the component s not
>> attached
>> so what i can do is make a component when it is created default attached
>> (that sounds also logical to me)
>> but then onAttach() is the first time not called (because that was the
>> constructor)
>>
>> If this is not a good idea we need another flag or something (on page)
>> where
>> we test really if the page
>> is in the right state. Because the whole attach cycle nothing should be
>> possible to change hierachy.
>>
>> johan
>>
>> On 5/14/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>>>
>>> hmm also now we don't test globally any more things can go wrong
>>>
>>> a component can't alter itself. But it can alter everything else!
>>>
>>> as i said it can do: parent.add/remove
>>>
>>> but it can also do: child.add /remove (because that one isn't in
>>> attaching
>>> yet...)
>>>
>>>
>>>
>>> On 5/14/07, Johan Compagner <[EMAIL PROTECTED] > wrote:
>>> >
>>> > the same goes i guess for attaching:
>>> >
>>> > setFlag(FLAG_ATTACHING, false);
>>> > setFlag(FLAG_ATTACHED, true);
>>> > attachChildren();
>>> >
>>> >
>>> > thats also wrong. The parent is attaching false but then the children
>>> > attach is called
>>> > so a child can do this:
>>> >
>>> > parent.remove(this)
>>> >
>>> > that would work fine now in attaching mode as far as i can see.
>>> >
>>> > johan
>>> >
>>> >
>>> > On 5/14/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>>> > >
>>> > > hmm this could go wrong now:
>>> > >
>>> > > setFlag(FLAG_RENDERING, true);
>>> > > onBeforeRenderChildren();
>>> > >
>>> > >
>>> > > we first set the flag in rendering then call the onBefore on all the
>>> > > childs
>>> > >
>>> > > so the parent is already i render mode (can't be changed) but the
>>> > > childs should be able to still alter the state
>>> > > thats a bit strange i think the rendering flag should be on true
>>> only
>>> > > if all the childs are also called? agree?
>>> > >
>>> > > johan
>>> > >
>>> > >
>>> > > On 5/14/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>>> > > >
>>> > > >
>>> > > >
>>> > > > I committed a fix to this this morning that I have confidence
>>> > > > in. Still
>>> > > > having problems due to this refactor. Who did it?
>>> > > >
>>> > > >
>>> > > > Jonathan Locke wrote:
>>> > > > >
>>> > > > >
>>> > > > > unless you can get to this fast, i'm going to guess a fix
>>> because
>>> > > > > we're blocked on this.
>>> > > > >
>>> > > > >
>>> > > > > Johan Compagner wrote:
>>> > > > >>
>>> > > > >> will check it out asap
>>> > > > >>
>>> > > > >> On 5/12/07, Jonathan Locke < [EMAIL PROTECTED]> wrote:
>>> > > > >>>
>>> > > > >>>
>>> > > > >>>
>>> > > > >>> Opened new blocking bug:
>>> > > > >>>
>>> > > > >>> https://issues.apache.org/jira/browse/WICKET-558
>>> > > > >>>
>>> > > > >>>
>>> > > > >>> Jonathan Locke wrote:
>>> > > > >>> >
>>> > > > >>> >
>>> > > > >>> > Because components are created in onBeforeRender in list
>>> views
>>> > > > (it
>>> > > > >>> calls
>>> > > > >>> > populateItem then), it is necessary for AJAX renderings now
>>> to
>>> > > > call
>>> > > > >>> > beforeRender on every component to be updated before
>>> > > > proceeding with
>>> > > > >>> the
>>> > > > >>> > render.
>>> > > > >>> >
>>> > > > >>> > It looks like AjaxRequestTarget.respondComponent should call
>>> > > > before
>>> > > > >>> render
>>> > > > >>> > on the component tree it's about to render. But I'm unsure
>>> if
>>> > > > this is
>>> > > > >>> the
>>> > > > >>> > right place to make the change. Johan can you look at this
>>> > > > since you
>>> > > > >>> were
>>> > > > >>> > doing this refactor and probably know all the details?
>>> > > > >>> >
>>> > > > >>> >
>>> > > > >>>
>>> > > > >>> --
>>> > > > >>> View this message in context:
>>> > > > >>>
>>> > > >
>>> http://www.nabble.com/New-attach-%3EbeforeRender-refactor-breaks-ajax-updating-of-list-views-tf3729131.html#a10443272
>>> > > > >>> Sent from the Wicket - Dev mailing list archive at Nabble.com
>>> .
>>> > > > >>>
>>> > > > >>>
>>> > > > >>
>>> > > > >>
>>> > > > >
>>> > > > >
>>> > > >
>>> > > > --
>>> > > > View this message in context:
>>> > > >
>>> http://www.nabble.com/New-attach-%3EbeforeRender-refactor-breaks-ajax-updating-of-list-views-tf3729131.html#a10609034
>>> > > > Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>> > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/New-attach-%3EbeforeRender-refactor-breaks-ajax-updating-of-list-views-tf3729131.html#a10614119
Sent from the Wicket - Dev mailing list archive at Nabble.com.
