View Full Version : image update problem

27 Dec 2010, 1:56 PM
I defined the following item in a panel:

xtype: 'box',
id: 'portrait',
autoEl: {
tag: 'img',
src: '/some/path/potrait.100x150.jpg',
width: 100,
height: 150
}, ...
Subsequently, a user can update his pic with the following code:

Ext.getCmp('portrait').getEl().dom.src = imgPath;
As var imgPath typically also equals to '/some/path/potrait.100x150.jpg', Ext probably thinks that the image has not changed and does not do a GET on that path upon update. However, it works if the path contained in imgPath is different.

Is there some workaround to this problem without working with changed filenames? Can the box/image component be forced in some way to refetch its image from the server even the src-path remains the same?


27 Dec 2010, 5:23 PM
This isn't really anything to do with Ext, it's just the way the browser behaves when you set the src of an img tag. If you set the src to the URL of any image that the browser has already cached it won't download it again. For example, if you keep switching the src between 2 different images you'll find it only downloads them both the first time.

You haven't explained why you want it to reload the same image so it's a little difficult to suggest a suitable workaround. Depending on the circumstances you might be able to use a dummy parameter on the image URL to avoid the caching. It could be a counter or timer-based. e.g.:

Ext.getCmp('portrait').getEl().dom.src = imgPath + '?' + new Date().getTime();Most servers will just ignore this extra parameter for a static file like a jpg.

28 Dec 2010, 1:38 PM
Thanks Skirtle,
I suspected this as well, still there was some hope for another solution...
The workaround does not work unfortunately, in both FF3.6 and IE8. I suppose both browser just consider the resource path without the parameters for their caching strategy.
Thus, I probably need to work with changing filenames, that's not too bitter, I just need to change my file upload algorithm.


28 Dec 2010, 2:38 PM
Browsers definitely don't ignore the parameters as part of their caching strategy, half the web would break if they started doing that.

How are you assessing that the workaround 'does not work'? I'm using Firebug with FF3.6 and I can see it making a new request each time I update the image.

You still haven't explained why you want to force the reload of a static image: it implies some sort of server-side magic. Perhaps explaining that a little would shed some light on what's going wrong?

30 Dec 2010, 12:52 PM
I'm using FF3.6 as well, with Firebug, and the latter does not report any GET of the updated image with the '?123' trick.

However, I have meanwhile changed to varying filenames, and that works perfectly.

The original reason for the 'sticky' filename was that there would have been always exactly the same path to an user's profile picture, i.e. not depending upon the uploaded filename. After the change, this is variable, and the server has to keep the path in the repository and can return it as HTTP location header.


30 Dec 2010, 1:37 PM
Glad you've got this working now but I can't figure out why that workaround wouldn't give the desired results. Do the original GET requests appear in Firebug as expected? If you use Firebug's element inspection tool on the img tag does it show the updated src in the HTML tab, including the '?123' stuff?