What I have done in the past is to simply update the src attribute of the 
image. The result is immediate and doesn't suffer from any cache issues.

Walter

On Sep 29, 2011, at 8:58 PM, ncubica wrote:

> i know you resolve your problem but It wont be easy if you delete from
> the dom the <img /> tag storing the actual images then... create new
> new Images() append to the div and finally add a query "cheat" link???
> just a shot...
> 
> best
> ncubica...
> 
> On 29 sep, 13:28, Phil Petree <phil.pet...@gmail.com> wrote:
>> I didnt address the caching because I had to look to see if I could find
>> where I had saved this link off the last time I had this problem... found
>> it!
>> 
>> The caching is probably on the browser side, not the server side.  Setting
>> the server side cache variables will only affect the page reload.
>> 
>> The browser knows better than to cache on refresh/reload BUT technically, to
>> the browser, you are not reloading and since the image has the same name it
>> doesn't really know that you need a refresh.
>> 
>> This guy had a solution that worked for me:http://www.irt.org/script/416.htm
>> 
>> I have also used the cheap trick of adding a random query string on to the
>> end of the image 
>> url:http://www.somedomain.com/images/newname.jpg?id=random_numberand since 
>> this
>> will always generate a new url, the browser will refresh the image.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Thu, Sep 29, 2011 at 1:04 PM, Phil Petree <phil.pet...@gmail.com> wrote:
>>> This is an interesting problem... my first reaction is that you'd want
>>> to use onComplete to update the div's instead of onSuccess.
>> 
>>> Test this with a couple of alerts and see which one gets called first and
>>> which is last (just as onCreate is the first call, onComplete is the last).
>> 
>>> To my way if thinking, if you wait until onComplete gets triggered before
>>> you do any UI updates, all the images on the server should be properly in
>>> place.
>> 
>>> On Thu, Sep 29, 2011 at 12:15 PM, Richard Quadling 
>>> <rquadl...@gmail.com>wrote:
>> 
>>>> On 29 September 2011 16:58, Chris Sansom <ch...@highway57.co.uk> wrote:
>>>>> On 29 Sep 2011, at 15:51, Richard Quadling wrote:
>> 
>>>>>> Does ALL the JS work take place inside the onSuccess callback?
>> 
>>>>>> The "Back in JS" bit has to be part of the onSuccess callback
>>>>>> otherwise it will happen out of sequence. The A in AJAX is potentially
>>>>>> the hiccough here.
>> 
>>>>> That's what I suspected but yes, all the 'back in JS' stuff does indeed
>>>> happen in the onSuccess. (I also tried onComplete, but got the same 
>>>> result.)
>>>> I think the problem may be that the div, inevitably, is replaced right at
>>>> the end of the process (at the end of the onSuccess), and only then is the
>>>> offending <img> tag unleashed, calling either the image itself or my little
>>>> php script... but then I'd have thought preloading it might help, but it
>>>> doesn’t seem to. I also tried loading it via a php exec() call to the image
>>>> script in advance of returning the output string to JS, but that didn’t
>>>> help.
>> 
>>>>> What also convinces me that you're right about the A in AJAX is that
>>>> when, for testing, I put a sleep(5) in the image script - which should hold
>>>> it up by a whole 5 seconds - the div is still replaced immediately. When I
>>>> first load the page (which also calls this script), I get a broken image
>>>> icon where the image should have been, replaced after 5 seconds by the
>>>> image, but when the div is replaced by the ajax call that doesn’t happen - 
>>>> I
>>>> just get no change of image as before.
>> 
>>>>> It really would be /so/ nice if I could get this working! It's for a
>>>> password-protected CMS, so the world at large will never get the benefit,
>>>> and I could simply reload the whole page instead of just the one div, but
>>>> it's become a challenge!
>> 
>>>> Create a test case where it goes wrong. Write new clean code that
>>>> doesn't want/need/use anything from the main project.
>> 
>>>> At best, this will be a small HTML page with some divs and images, a
>>>> JS file to allow the onclick to fire the AJAX code, along with the
>>>> onsuccess and the server side code to handle the request and to return
>>>> the new HTML markup.
>> 
>>>> Without seeing the server and client side code, you are going to be
>>>> stuck with a limited level of support.
>> 
>>>> If you can't reduce the problem to something that can be read, I doubt
>>>> anyone can realistically provide any more ideas on this.
>> 
>>>> --
>>>> Richard Quadling
>>>> Twitter : EE : Zend : PHPDoc
>>>> @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
>> 
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "Prototype & script.aculo.us" group.
>>>> To post to this group, send email to
>>>> prototype-scriptaculous@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> prototype-scriptaculous+unsubscr...@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/prototype-scriptaculous?hl=en.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Prototype & script.aculo.us" group.
> To post to this group, send email to prototype-scriptaculous@googlegroups.com.
> To unsubscribe from this group, send email to 
> prototype-scriptaculous+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/prototype-scriptaculous?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.

Reply via email to