Ok you're right, it all makes perfect sense now. Thanks again.
On 20/03/2012 3:27 AM, Martin Grigorov wrote:
Hi,
On Mon, Mar 19, 2012 at 6:18 PM, Bertrand Guay-Paquet
<ber...@step.polymtl.ca> wrote:
Thanks for the explanation Martin.
I don't fully understand your second paragraph though. The
style/locale/variation can indeed change between ajax requests and I don't
dispute that. However, that is also the case between non-ajax requests but
these don't get the anticache parameter added to their Image src url.
Shouldn't adding the anticache parameter be independent of the type of
request? With the current behavior, I get the following sequence or urls:
-First page display:
src = resources/thumbs/pid140.png
-Ajax request containing the image:
src = resources/thumbs/pid140.png?antiCache=1332169642904
-Refresh of page or setResponsePage(getPage()):
src = resources/thumbs/pid140.png<--- can retrieve from cache,
If you don't want it to be loaded from cache then use NonCachingImage.
I tried to explain that if you add an image to AjaxRequestTarget then
Wicket by default assumes you updated this image and it should be
re-painted, i.e. no cached one should be shown. You can override this
default behavior (and you said below that you are going to do it).
Life is not perfect... We just try to make it better.
Any sane suggestions for improvement will be considered!
This means that if no other steps are taken (e.g. disabling caching at the
ResourceRef level, changing src url based on style/locale/variation, using
NonCachingImage), adding the anti-cache parameter is not enough.
Maybe I'm missing something since I only use shared resources currently.
I'll go ahead and create my own CachingImage subclass.
On 19/03/2012 10:21 AM, Martin Grigorov wrote:
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
---------------------------------------------------------------------
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
