Images, ajax requests and caching

[Bertrand Guay-Paquet <be...@step.polymtl.ca>]

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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Images, ajax requests and caching

[Bertrand Guay-Paquet <be...@step.polymtl.ca>]

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
> <be...@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
>>> <be...@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
>>>>> <be...@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-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail:users-help@wicket.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail:users-help@wicket.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail:users-help@wicket.apache.org
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Images, ajax requests and caching

[Martin Grigorov <mg...@apache.org>]

Hi,

On Mon, Mar 19, 2012 at 6:18 PM, Bertrand Guay-Paquet
<be...@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
>> <be...@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
>>>> <be...@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-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail:users-help@wicket.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail:users-help@wicket.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail:users-help@wicket.apache.org
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Images, ajax requests and caching

[Bertrand Guay-Paquet <be...@step.polymtl.ca>]

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,

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
> <be...@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
>>> <be...@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-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail:users-help@wicket.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail:users-help@wicket.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail:users-help@wicket.apache.org
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Images, ajax requests and caching

[Martin Grigorov <mg...@apache.org>]

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
<be...@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
>> <be...@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Images, ajax requests and caching

[Bertrand Guay-Paquet <be...@step.polymtl.ca>]

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
> <be...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Images, ajax requests and caching

[Igor Vaynberg <ig...@gmail.com>]

we have a noncachingimage subclass... :)

-igor

On Sun, Mar 18, 2012 at 9:33 PM, Bertrand Guay-Paquet
<be...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org