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.

Reply via email to