Yeah, I though Michel's reply was a little snippy too. But that aside, he's
right on the specific point that a synchronous Ajax call is to be avoided at
all cost.
It's even worse than he said: In a single-threaded browser like Firefox,
*all* browser windows and tabs are locked up until your Ajax call completes.
If your server doesn't respond - or if your visitor loses their Internet
connection momentarily - it locks up not just your site but all sites they
have open.
There must be a way you can structure your code to use ordinary asynchronous
Ajax. After you've done that homework, if the solution doesn't come to mind,
post some more details and we can help sort it out.
-Mike
On Thu, Nov 5, 2009 at 6:11 PM, RayJames <cdlcollege.rayja...@gmail.com>wrote:
> Man, that felt like an ass chewing but I needed it. :) I am going to
> do some more homework and see how to put the advice you gave me to
> good use. Thanks for your time Michel. I really appreciate it.
>
> Ray James.
>
> On Nov 5, 2:42 pm, Michel Belleville <michel.bellevi...@gmail.com>
> wrote:
> > 2009/11/5 RayJames <cdlcollege.rayja...@gmail.com>
> >
> > > Hi Michel, I think I might have confused you a bit. The user is not
> > > necessarily my concern.
> >
> > Well... Then I guess it's not necessarily a good thing you design UI
> because
> > it's all about the user. Ultimately, you're designing machines to work
> for
> > humans, and when you're designing user interfaces you're at the
> "ultimate"
> > step before the human uses the tools. If the user is not your concern
> here
> > you've picked the wrong part of the job. Really.
> >
> > > The code running in the background that sends
> > > calls to my api while the user is viewing the course is.
> >
> > Of course it is.
> >
> > > These calls
> > > consist of functions that Initialize the learner session, terminate
> > > the learner session, set and get values from the LMS as well as a few
> > > error handling calls.
> >
> > Of course they do.
> >
> > > Every time the course code calls the api the
> > > api is supposed to execute the call and return either data, true/
> > > false, or both.
> >
> > Of course it is.
> >
> > > The problem is that on the Initialize and Terminate
> > > calls, nothing should happen until the api returns a true or false.
> >
> > Well, if by nothing you mean nothing both server-side AND client-side I
> > agree with you, you need synchronous calls. That will also prevent your
> user
> > from doing anything between the beginning of the call and the end. Even
> > scrolling the page, or opening an outside link in a new tab, anything AT
> ALL
> > until the call finishes. I don't know you but I find that drastic.
> >
> > > Once that happens, then the other calls WILL just be called in the
> > > background async style while the user is engaged with the course. I
> > > think this is the best way, because putting a "waiting" class could
> > > result in longer waiting times for the execution of the functions and
> > > could still possibly timeout before the code finishes. What do you
> > > think?
> >
> > I respectfully disagree, it is my informed opinion that adding a waiting
> > class will not result in significant performances losses unless you botch
> > the job (and I mean really botch the job, like adding the waiting class
> to
> > any element of the page instead of the topmost element that needs it) or
> the
> > calls are very close (and again I mean really very close, the kind of
> close
> > that would make your interface unusable because synchronous calls would
> > freeze it every odd second).
> >
> > The only constraint here is that you round up elements that must not be
> > triggered between the beginning and the end of your pseudo-synchronous
> calls
> > and give them this little trigger :
> > $('.the_waiting_class .any_element_you_want_to_block').live('click',
> > function() { return false; });
> >
> > The event will only be triggered when the targets match (so when
> > the_waiting_class is given to their common parent), it will work on
> elements
> > added to the dom during ajax or whatever script, and no user will notice
> any
> > performance problem as .live uses bubbling to catch the events.
> >
> > I apologize for not making myself clear enough. This is
> >
> > > actually a fairly complex system and will be awesome when finished.
> >
> > I'm sure it will, but remember UI is one of the most important things
> that
> > make the difference between "awesome" and "I'm tired of this site that
> just
> > freezes on me, let's google away".
> >
> > > Keep an eye on Drupal and wait for it to come out as a module. I will
> > > be opening all my code up as open source once it is finished. Thanks.
> >
> > Hope you do well.
> >
> > Michel Belleville
>
