[Proto-Scripty] Image cache problem with Ajax
I don't know if this is really something I can fix via Prototype, or if it's in any way a Prototype issue, but I'll try here first. Here is my problem - which unfortunately I can’t show you because I'm only developing it on my local system at the moment - slightly simplified: I have a pair of images on a page, one above the other. The user should be able to click the second one to swap them round, but I don't mean merely swapping their position on the page: this involves renaming the files. On the server, the first image is given a completely new name and the second is renamed with the first's old name. The div containing the two is then replaced by the magic of Ajax, except... the problem is that the image with the old name is cached (I think), so although the second image is indeed replaced by the first with its brand new name, the first image is unchanged, either because the previous image with that name is stuck in the cache or because it hasn’t had time to be reloaded due to the asynchronous nature of the process. Either way, I end up with two of the same image. If I then refresh the page altogether, I get the correct images. 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. So is my problem the cache? Or is it simply that the scripts run faster than the replacement image can be loaded? I've tried various things to stop it caching, such as loading the top image via a tiny php script which sends all manner of no-cache type headers then does fpassthru, fread or whatever (I've tried it various ways) - this made no difference. I even tried including a sleep(1) command in this script! - no good. I've also tried preloading the image in JS before the new div is output - no good. Should I be trying to subvert (pervert?) Ajax into running synchronously somehow? I'm quite prepared to accept that I may be approaching this whole problem bass-ackwards, and would be grateful for any pointers. * I did this via an include file because I need to do the same processing when the page is initially loaded, so this seemed the most efficient way, code-wise. -- 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 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.
[Proto-Scripty] Re: Image cache problem with Ajax
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.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
Re: [Proto-Scripty] Re: Image cache problem with Ajax
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.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
[Proto-Scripty] Re: Future of Prototype.js
ok ... So T.J. I know you not have the ultimate decision for designate a candidate for any position at Prototype community but certanly you are the most near with the core team. So I would like to know if you could email one of them and try to start designate person for revitalize this community... I have a good widgets base with prototype and I could build more... that's not a problem... but we need to designate a OFFICIAL Site for hosted documentation and more important EXAMPLES. scripteka is a good place to fine this, BUT doesn't have any space for comments or is NOT organice in a way where you can easy find the widget you are expect or more important ask to the community where to find it or maybe build it by more experience developer, I think is why jquery have grow that huge beside of the money behind it. Cause a lot of designers with a lack knowledge of javascript can use it... happend with php vs java... and a lot more examples out there, We have to reinvent the way of how we communicate prototype... to everybody out there So please talk with them, I have a fully compromise for work with this project a least 1 year... and this is because I explote my javascript knowledge because this framework... and care about it. Best Ncubica... On 27 sep, 08:58, Walter Lee Davis wa...@wdstudio.com wrote: On Sep 27, 2011, at 12:00 AM, Marty Amberg wrote: One more thing. Chevy and Ford and Honda, make lots of cars but that does not mean they produce the best vehicles. It be much for fun driving a Ferrari and they don't make as many. The point being, just cause something is popular does not mean its the best and there are a lot of other frameworks out there.. One talking point that got trotted out lots of times during the Dark Ages of Macintosh vs. Windows was that cockroaches were the largest population in numbers, but you wouldn't want one to write you a sonnet. Walter -- 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] Re: Image cache problem with Ajax
Walter, you're right that's generally all that's needed but since one img name would stay the same the browser would look in cache first and not reload the image... which is what he's experiencing. On Sep 29, 2011 9:39 PM, Walter Lee Davis wa...@wdstudio.com wrote: 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
Re: [Proto-Scripty] Re: Future of Prototype.js
Might have been asleep during my previous google searches but I found tj's site http://proto-scripty.wikidot.com today which seems like answers questions of what I would want and think prototype needs to grow.No sense in reinventing something that is there which is what I ahd posted before. A place for solid examples and other useful things. On 9/29/2011 9:43 PM, ncubica wrote: ok ... So T.J. I know you not have the ultimate decision for designate a candidate for any position at Prototype community but certanly you are the most near with the core team. So I would like to know if you could email one of them and try to start designate person for revitalize this community... I have a good widgets base with prototype and I could build more... that's not a problem... but we need to designate a OFFICIAL Site for hosted documentation and more important EXAMPLES. scripteka is a good place to fine this, BUT doesn't have any space for comments or is NOT organice in a way where you can easy find the widget you are expect or more important ask to the community where to find it or maybe build it by more experience developer, I think is why jquery have grow that huge beside of the money behind it. Cause a lot of designers with a lack knowledge of javascript can use it... happend with php vs java... and a lot more examples out there, We have to reinvent the way of how we communicate prototype... to everybody out there So please talk with them, I have a fully compromise for work with this project a least 1 year... and this is because I explote my javascript knowledge because this framework... and care about it. Best Ncubica... On 27 sep, 08:58, Walter Lee Daviswa...@wdstudio.com wrote: On Sep 27, 2011, at 12:00 AM, Marty Amberg wrote: One more thing. Chevy and Ford and Honda, make lots of cars but that does not mean they produce the best vehicles. It be much for fun driving a Ferrari and they don't make as many. The point being, just cause something is popular does not mean its the best and there are a lot of other frameworks out there.. One talking point that got trotted out lots of times during the Dark Ages of Macintosh vs. Windows was that cockroaches were the largest population in numbers, but you wouldn't want one to write you a sonnet. Walter -- 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.
