Hi, I'm afraid you dont' really get what IComponentResolver is for. The purpose is to allow creating components from markup for a very short span of time - basically while the components are rendered and they should be removed immediate afterwards. So if you call visitChildren from another component, the resolved component will not be available.
What changed in beta 4 is that we now remove the component immediately after it's rendered (inside the autoAdd call) because otherwise It caused us a nasty memory leak. Also from what I can guess you are doing your solution is really fragile, as you create a component during another component's rendering and then want to interact with that component form other place - but this depends on order in which are components rendered - doesn't seem like a solid solution. One thing necessary to realize is that in current status Wicket only knows the markup that belongs to each component during the render phase, which is wrong place to create components (except for components with extremely short lifespan added and rendered through auto add. but this is internal stuff even though it's not properly marked as such). -Matej On 10/17/07, Ari Suutari <[EMAIL PROTECTED]> wrote: > Hi, > > But it looks like that in this case the visitChilder is performed during > render, and it still won't find stuff added by autoAdd. > > It is not a very robust design if the behaviour of autoAdd/visitChilder > would require some kind of component-hierarchy fine-tuning. This kind > of approach might work with static-kind-of applications, but at least > for us, the content in applications is very dynamic and interface like > IComponentResolver has been very handy. > > Just a wild guess here - maybe the processing of IComponentResolver stuff > was done earlier in beta3 than in beta4. Not getting this fixed can be pretty > annoying > for us - we have a couple of hundreds of pages done with wicket which rely > on this. > > We could of course try to step back in time with svn to see which change > has broken this, but I don't know how much sense it will make unless > developers are not going to admit that this is a problem. > > Ari S. > > > ----- Original Message ----- > From: "Matej Knopp" <[EMAIL PROTECTED]> > To: <users@wicket.apache.org> > Sent: Wednesday, October 17, 2007 2:15 PM > Subject: Re: VisitChildren + IComponentResolver broken in beta 4? > > > > It depends on when you call the visitChildren method. The idea is that > > resolved components are on page only during page render. Otherwise > > they are removed from page. > > > > -Matej > > > > On 10/17/07, Juha Alatalo <[EMAIL PROTECTED]> wrote: > >> In the JIRA issue following was commented: > >> "This doesn't seem to be a bug in Wicket. In fact, the bug was that it > >> worked before. ..." > >> > >> This new "fix" is kind of a show stopper for us. What actually is the > >> idea of the componentResolver? Functions like visitChildren works for > >> normally added component. Shouldn't those functions work also for > >> components that are added using IComponentResolver as long as those are > >> visible? > >> > >> - Juha > >> > >> Juha Alatalo wrote: > >> > https://issues.apache.org/jira/browse/WICKET-1077 > >> > > >> > - Juha > >> > > >> > Matej Knopp wrote: > >> >> Please create a JIRA entry and assign the example to it. > >> >> > >> >> Thanks. > >> >> > >> >> -Matej > >> >> > >> >> On 10/15/07, Juha Alatalo <[EMAIL PROTECTED]> wrote: > >> >>> Hi, > >> >>> > >> >>> If the components are added on the page using ComponentResolver, > >> >>> visitChildren() method seems to be working incorrectly. Created > >> >>> following example which works in beta 3 but not in beta 4. > >> >>> > >> >>> http://download.syncrontech.com/public/VisitChildrenExample.zip > >> >>> > >> >>> - Juha > >> >>> > >> >>> --------------------------------------------------------------------- > >> >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >>> For additional commands, e-mail: [EMAIL PROTECTED] > >> >>> > >> >>> > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > >> >> > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
