Hi, as Frank has already stated, it's not the tests that should be fixed. It is the AjaxRequestTarget code. I'm going to look at it right now.
But maybe I should make some tests with header contribution, that would make more sense. I don't like the idea of storing more things in page. I just can find any other way currently. You render a page with component A. Then you ajax-replace it with component B (which has header contribution). After then you ajax-replace it with component C. And finally, you replace C again with B. This should not send any header contribution, because B has already been rendered. So you have to store information this somewhere between requests. I don't mind storing it on client, but it might be problematic with big contributions (large javascripts or style definitions). -Matej Juergen Donnerstag wrote: > Matej, may I suggest you update the junit tests as well which are now > failing due to the header changes. I think it is good practice to > always run the tests before committing changes. > > Juergen > > On 7/6/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: >> Yeah, it's either a bandwidth optimization or a memory usage optimization. >> >> Eelco >> >> >>> I'm not sure I like that idea. It means we need to store even more >>> data in the Page (or any of its components or behaviors) (= Session >>> because of clusters). How to uniquely identify a header contributions >>> without wasting to much session memory? >>> It can become realy ugly. Think about a panel with two equal ajax >>> components, one visible and the other not. Than you enable the second. >>> In theory you don't need to return the header because the first >>> component provided it already. And of course the components may be on >>> different levels in the component hierarchy. One the other hand we've >>> got most of it already (except the store). May be not that difficult >>> after all. The whole "header needs render or not" should become a >>> Strategy. Better usage of proper patterns. >>> >>> Juergen >> Using Tomcat but need to do more? Need to support web services, security? >> Get stuff done quickly with pre-integrated technology to make your job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> _______________________________________________ >> Wicket-develop mailing list >> Wicket-develop@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wicket-develop >> > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop