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.
