Hi, The idea is if you add an image to an AjaxRequestTarget then Wicket assumes this image needs to be re-painted. This is the safer approach because otherwise the user will add it to the target and the image will not change. Then we have to explain the user that he has to do something more additionally.
Maybe the only way to optimize even further is to add the anticache param only if static String url is used (in contrast to resource or resourcereference). But even in this case the style/locale/variation may be changed and the image should be updated again ... So the current approach is the most common - let the developer decide whether the image should be updated or not. Just override org.apache.wicket.markup.html.image.Image#shouldAddAntiCacheParameter On Mon, Mar 19, 2012 at 4:07 PM, Bertrand Guay-Paquet <ber...@step.polymtl.ca> wrote: > Indeed, but I don't understand how that helps in my case. NonCachingImage > takes the behavior of Image one step further by always adding an "anticache" > parameter to images (i.e. for ajax and normal requests). Wicket currently > has : > > Image -> Cached for normal requests, never cached for ajax requests > NonCachingImage -> Never cached for ajax and normal requests > > What I want is a cachable image to avoid unnecessary client requests for > thumbnails. Like I said, such a class is very easy to do, but maybe the > current behavior of Wicket is not desirable. > > > On 19/03/2012 1:25 AM, Igor Vaynberg wrote: >> >> we have a noncachingimage subclass... :) >> >> -igor >> >> On Sun, Mar 18, 2012 at 9:33 PM, Bertrand Guay-Paquet >> <ber...@step.polymtl.ca> wrote: >>> >>> Hi, >>> >>> I have image resources which fetch the proper thumbnail picture stored in >>> a >>> DB based on the image's file name. I used the file name instead of >>> parameters to make sure client-side caching would work. By chance, I just >>> discovered that the images are always reloaded on ajax requests. >>> >>> This is caused by Image#shouldAddAntiCacheParameter and >>> Image#addAntiCacheParameter which always add an "anticache" parameter to >>> image src URLs on ajax requests. >>> >>> In my case, the images are added to ajax requests as part of a table >>> update >>> containing lots of thumbnails so it's definitely counter-productive. I >>> can >>> see the need for anticaching for dynamically generated images which >>> change >>> per request, but should this be the default behavior? >>> >>> Of course, I can easily work around this issue by subclassing Image, but >>> I >>> wanted to bring this to attention. At the very least, I would suggest >>> creating a subclass (CachingImage?) of Image in core which does not do >>> anticaching for stateless resource references. >>> >>> Regards, >>> Bertrand >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
