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

Reply via email to