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

Reply via email to