Re: VisitChildren + IComponentResolver broken in beta 4?
Great! Thanks a lot Matej. When this fix is coming? - Juha Matej Knopp wrote: Well, I believe we can keep the component instance until the end of request and then clean it up in detach, would this help you? (it still wouldn't be the same as before the fix, as the instance was (supposed to be) cleaned during the next request, but this means keeping additional state for no good reason. -Matej On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: 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. Well. We have been using this from very early days of wicket without a problem. Also, there is no mention about this very short time in javadoc. Actually, if the autoAdded component was there previously for longer time and is now removed immediately this is a quite big change of behaviour if looking it from the application. 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. We have some rather large sites running with wicket 1.2 using autoAdd stuff, haven't noticed any huge leaks there. Couldn't you consider any other alternatives for fixing that leak instead of insisting that we are doing something so wrong ? I really like all these IWhateverNiceInterface -things in wicket. Usually, when there is a need in application architecture, wicket has had a nice interface to support it. But it seems that it is very easy to get yourself burnt when using them, since they tend to get either rewritten or their behaviour changes Which is not a problem for someone who writes a smaller web applications with just a couple of pages. But for someone who does larger ones, it's not so nice. Ari S. 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
Re: VisitChildren + IComponentResolver broken in beta 4?
the fix is in. Still i don't get that you depend on an auto add component from another component For example is that auto add component always rendered before that other componenet? How do you exactly use it? And why? johan On 10/22/07, Juha Alatalo [EMAIL PROTECTED] wrote: Great! Thanks a lot Matej. When this fix is coming? - Juha Matej Knopp wrote: Well, I believe we can keep the component instance until the end of request and then clean it up in detach, would this help you? (it still wouldn't be the same as before the fix, as the instance was (supposed to be) cleaned during the next request, but this means keeping additional state for no good reason. -Matej On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: 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. Well. We have been using this from very early days of wicket without a problem. Also, there is no mention about this very short time in javadoc. Actually, if the autoAdded component was there previously for longer time and is now removed immediately this is a quite big change of behaviour if looking it from the application. 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. We have some rather large sites running with wicket 1.2 using autoAdd stuff, haven't noticed any huge leaks there. Couldn't you consider any other alternatives for fixing that leak instead of insisting that we are doing something so wrong ? I really like all these IWhateverNiceInterface -things in wicket. Usually, when there is a need in application architecture, wicket has had a nice interface to support it. But it seems that it is very easy to get yourself burnt when using them, since they tend to get either rewritten or their behaviour changes Which is not a problem for someone who writes a smaller web applications with just a couple of pages. But for someone who does larger ones, it's not so nice. Ari S. 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
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]
Re: VisitChildren + IComponentResolver broken in beta 4?
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]
Re: VisitChildren + IComponentResolver broken in beta 4?
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]
Re: VisitChildren + IComponentResolver broken in beta 4?
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. Well. We have been using this from very early days of wicket without a problem. Also, there is no mention about this very short time in javadoc. Actually, if the autoAdded component was there previously for longer time and is now removed immediately this is a quite big change of behaviour if looking it from the application. 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. We have some rather large sites running with wicket 1.2 using autoAdd stuff, haven't noticed any huge leaks there. Couldn't you consider any other alternatives for fixing that leak instead of insisting that we are doing something so wrong ? I really like all these IWhateverNiceInterface -things in wicket. Usually, when there is a need in application architecture, wicket has had a nice interface to support it. But it seems that it is very easy to get yourself burnt when using them, since they tend to get either rewritten or their behaviour changes Which is not a problem for someone who writes a smaller web applications with just a couple of pages. But for someone who does larger ones, it's not so nice. Ari S. 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
Re: VisitChildren + IComponentResolver broken in beta 4?
Well, I believe we can keep the component instance until the end of request and then clean it up in detach, would this help you? (it still wouldn't be the same as before the fix, as the instance was (supposed to be) cleaned during the next request, but this means keeping additional state for no good reason. -Matej On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: 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. Well. We have been using this from very early days of wicket without a problem. Also, there is no mention about this very short time in javadoc. Actually, if the autoAdded component was there previously for longer time and is now removed immediately this is a quite big change of behaviour if looking it from the application. 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. We have some rather large sites running with wicket 1.2 using autoAdd stuff, haven't noticed any huge leaks there. Couldn't you consider any other alternatives for fixing that leak instead of insisting that we are doing something so wrong ? I really like all these IWhateverNiceInterface -things in wicket. Usually, when there is a need in application architecture, wicket has had a nice interface to support it. But it seems that it is very easy to get yourself burnt when using them, since they tend to get either rewritten or their behaviour changes Which is not a problem for someone who writes a smaller web applications with just a couple of pages. But for someone who does larger ones, it's not so nice. Ari S. 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
Re: VisitChildren + IComponentResolver broken in beta 4?
Hi, Well, I believe we can keep the component instance until the end of request and then clean it up in detach, would this help you? (it still wouldn't be the same as before the fix, as the instance was (supposed to be) cleaned during the next request, but this means keeping additional state for no good reason. I think for our case this could be perfect solution. We don't need the state after the render, the application is dependend on it only during it. Thanks, Ari S. -Matej On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: 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. Well. We have been using this from very early days of wicket without a problem. Also, there is no mention about this very short time in javadoc. Actually, if the autoAdded component was there previously for longer time and is now removed immediately this is a quite big change of behaviour if looking it from the application. 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. We have some rather large sites running with wicket 1.2 using autoAdd stuff, haven't noticed any huge leaks there. Couldn't you consider any other alternatives for fixing that leak instead of insisting that we are doing something so wrong ? I really like all these IWhateverNiceInterface -things in wicket. Usually, when there is a need in application architecture, wicket has had a nice interface to support it. But it seems that it is very easy to get yourself burnt when using them, since they tend to get either rewritten or their behaviour changes Which is not a problem for someone who writes a smaller web applications with just a couple of pages. But for someone who does larger ones, it's not so nice. Ari S. 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
Re: VisitChildren + IComponentResolver broken in beta 4?
Hi, Well, I believe we can keep the component instance until the end of request and then clean it up in detach, would this help you? (it still wouldn't be the same as before the fix, as the instance was (supposed to be) cleaned during the next request, but this means keeping additional state for no good reason. I think for our case this could be perfect solution. We don't need the state after the render, the application is dependend on it only during it. Thanks, Ari S. -Matej On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: 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. Well. We have been using this from very early days of wicket without a problem. Also, there is no mention about this very short time in javadoc. Actually, if the autoAdded component was there previously for longer time and is now removed immediately this is a quite big change of behaviour if looking it from the application. 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. We have some rather large sites running with wicket 1.2 using autoAdd stuff, haven't noticed any huge leaks there. Couldn't you consider any other alternatives for fixing that leak instead of insisting that we are doing something so wrong ? I really like all these IWhateverNiceInterface -things in wicket. Usually, when there is a need in application architecture, wicket has had a nice interface to support it. But it seems that it is very easy to get yourself burnt when using them, since they tend to get either rewritten or their behaviour changes Which is not a problem for someone who writes a smaller web applications with just a couple of pages. But for someone who does larger ones, it's not so nice. Ari S. 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
VisitChildren + IComponentResolver broken in beta 4?
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]
Re: VisitChildren + IComponentResolver broken in beta 4?
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]
Re: VisitChildren + IComponentResolver broken in beta 4?
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]
