Re: [Proto-Scripty] Image cache problem with Ajax
Right - time to deal with all these helpful answers I've been getting, but first, to save time, let me say... it's fixed! And a very simple fix it was too, which I /thought/ I'd already tried... On 29 Sep 2011, at 17:15, Richard Quadling wrote: Create a test case where it goes wrong. Write new clean code that doesn't want/need/use anything from the main project. I had just prepared such a project when I found the answer among the answers below! And on 29 Sep 2011, at 18:04, Phil Petree 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). Well I had already tried onComplete and it made no difference, but I tried your suggestion nevertheless and sure enough, wherever I put the alerts in the code of the callbacks, onSuccess always emerged before onComplete. It also didn’t matter (as I assumed it wouldn't) if I put the onComplete before the onSuccess in the code. Then on 29 Sep 2011, at 18:28, Phil Petree wrote: This guy had a solution that worked for me: http://www.irt.org/script/416.htm I had already tried using the time in a similar way to this, but it didn’t work. However, in the same message... 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_number and since this will always generate a new url, the browser will refresh the image. That was the one! As I say, I thought I'd done that - or something very like it - in my numerous attempts at different solutions, but I obviously didn’t do exactly this, and it seems to work reliably every time in a suitably bulletproof fashion. So simple! It also seems to confirm that my initial suspicions were correct, and it is after all a caching issue, not to do with, er, asynchronicity (if that's a word - if not, Ive just invented it, so there). So many thanks for your time and thoughts, Richard and Phil, also ncubica and Walter for chipping in. -- Cheers... Chris Highway 57 Web Development -- http://www.highway57.co.uk/ -- 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.
Re: [Proto-Scripty] Image cache problem with Ajax
On 30 September 2011 10:27, Chris Sansom ch...@highway57.co.uk wrote: Right - time to deal with all these helpful answers I've been getting, but first, to save time, let me say... it's fixed! And a very simple fix it was too, which I /thought/ I'd already tried... On 29 Sep 2011, at 17:15, Richard Quadling wrote: Create a test case where it goes wrong. Write new clean code that doesn't want/need/use anything from the main project. I had just prepared such a project when I found the answer among the answers below! And on 29 Sep 2011, at 18:04, Phil Petree 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). Well I had already tried onComplete and it made no difference, but I tried your suggestion nevertheless and sure enough, wherever I put the alerts in the code of the callbacks, onSuccess always emerged before onComplete. It also didn’t matter (as I assumed it wouldn't) if I put the onComplete before the onSuccess in the code. Then on 29 Sep 2011, at 18:28, Phil Petree wrote: This guy had a solution that worked for me: http://www.irt.org/script/416.htm I had already tried using the time in a similar way to this, but it didn’t work. However, in the same message... 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_number and since this will always generate a new url, the browser will refresh the image. That was the one! As I say, I thought I'd done that - or something very like it - in my numerous attempts at different solutions, but I obviously didn’t do exactly this, and it seems to work reliably every time in a suitably bulletproof fashion. So simple! It also seems to confirm that my initial suspicions were correct, and it is after all a caching issue, not to do with, er, asynchronicity (if that's a word - if not, Ive just invented it, so there). So many thanks for your time and thoughts, Richard and Phil, also ncubica and Walter for chipping in. -- Cheers... Chris Highway 57 Web Development -- http://www.highway57.co.uk/ -- 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. onFailure / onSuccess is in response to a working result from the AJAX call. onComplete is in response to the AJAX mechanism shutting down. onComplete will always be called, but it isn't its job to deal with the data from the call. That is onSuccess. If the call failed for some reason, onComplete wouldn't have any data to work with and could make things worse. I use onCreate and onComplete to turn on/off a little spinner showing that the app is doing something behind the scenes. -- 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.
Re: [Proto-Scripty] Image cache problem with Ajax
On 30 Sep 2011, at 12:32, Richard Quadling wrote: onFailure / onSuccess is in response to a working result from the AJAX call. onComplete is in response to the AJAX mechanism shutting down. onComplete will always be called, but it isn't its job to deal with the data from the call. That is onSuccess. If the call failed for some reason, onComplete wouldn't have any data to work with and could make things worse. I use onCreate and onComplete to turn on/off a little spinner showing that the app is doing something behind the scenes. Right - thanks. That could be useful. -- Cheers... Chris Highway 57 Web Development -- http://www.highway57.co.uk/ -- 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.
Re: [Proto-Scripty] Image cache problem with Ajax
On 30 September 2011 12:53, Chris Sansom ch...@highway57.co.uk wrote: On 30 Sep 2011, at 12:32, Richard Quadling wrote: onFailure / onSuccess is in response to a working result from the AJAX call. onComplete is in response to the AJAX mechanism shutting down. onComplete will always be called, but it isn't its job to deal with the data from the call. That is onSuccess. If the call failed for some reason, onComplete wouldn't have any data to work with and could make things worse. I use onCreate and onComplete to turn on/off a little spinner showing that the app is doing something behind the scenes. Right - thanks. That could be useful. -- Cheers... Chris Highway 57 Web Development -- http://www.highway57.co.uk/ -- 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. And if you use the Ajax.Responders (http://api.prototypejs.org/ajax/Ajax/Responders/), you can define that behaviour once for all of the ajax calls you make, rather than having to add it to each individual ajax instance. -- 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.
Re: [Proto-Scripty] Image cache problem with Ajax
I never meant to imply that onComplete did the same thing as onSuccess, what I meant to state was that onComplete ALWAYS gets called last. onSuccess can always set a flag and onComplete can do the UI updates right before turning off the spinner. This is useful if you're experiencing those asynchronicity problems that the OP thought he had... Almost a poor mans semaphore manager. On Fri, Sep 30, 2011 at 7:53 AM, Chris Sansom ch...@highway57.co.uk wrote: On 30 Sep 2011, at 12:32, Richard Quadling wrote: onFailure / onSuccess is in response to a working result from the AJAX call. onComplete is in response to the AJAX mechanism shutting down. onComplete will always be called, but it isn't its job to deal with the data from the call. That is onSuccess. If the call failed for some reason, onComplete wouldn't have any data to work with and could make things worse. I use onCreate and onComplete to turn on/off a little spinner showing that the app is doing something behind the scenes. Right - thanks. That could be useful. -- Cheers... Chris Highway 57 Web Development -- http://www.highway57.co.uk/ -- 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.
Re: [Proto-Scripty] Image cache problem with Ajax
On 30 September 2011 13:09, Phil Petree phil.pet...@gmail.com wrote: I never meant to imply that onComplete did the same thing as onSuccess, what I meant to state was that onComplete ALWAYS gets called last. onSuccess can always set a flag and onComplete can do the UI updates right before turning off the spinner. This is useful if you're experiencing those asynchronicity problems that the OP thought he had... Almost a poor mans semaphore manager. I'd be wary of performing activities in onComplete which are based upon results in onSuccess. I've patched my Prototype to allow me to create a responder for any callback (including statuses) as well as the ability for the responders to block the local callback. Primarily this is for AJAX error handling. I can return an appropriate status from the server, or the request can fail (for something out side of my control) and all the handling is done at the responder level. This makes my specific AJAX calls much cleaner as they only need the onSuccess callback. This mechanism works very well for me. -- 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.
Re: [Proto-Scripty] Image cache problem with Ajax
On 29 Sep 2011, at 15:00, Chris Sansom wrote: I've tried various things to stop it caching, such as loading the top image via a tiny php script Forgot to mention, before anyone else does, that the first thing I tried, after Googling, was to put various query strings [such as '?' + (new Date()).getTime()] after the file name in the img tag. Didn’t work. -- Cheers... Chris Highway 57 Web Development -- http://www.highway57.co.uk/ -- 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.
Re: [Proto-Scripty] Image cache problem with Ajax
On 29 September 2011 15:00, Chris Sansom ch...@highway57.co.uk wrote: In sequence, this happens: - User clicks image - Ajax request is created, running a php script with various parameters, in which... - ...the necessary renaming takes place (which involves checking for duplicates etc.), then... - ...a php file is included* which does various processing to build up an output string for the replacement div... - ...in which all are replaced by [] so as not to confuse the xml return. - Back in JS, the [] are changed back to and the containing div is replaced. 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. Regards, Richard. -- 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.
Re: [Proto-Scripty] Image cache problem with Ajax
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! -- Cheers... Chris Highway 57 Web Development -- http://www.highway57.co.uk/ -- 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.
Re: [Proto-Scripty] Image cache problem with Ajax
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.
Re: [Proto-Scripty] Image cache problem with Ajax
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.comwrote: 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.
Re: [Proto-Scripty] Image cache problem with Ajax
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_number and 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.comwrote: 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.
