getJSON - need some direction please.

[RayJames]

Hi everyone, thanks is advance for your help.

I am working on a getJSON call to my website from a popup window that
is connected through a Run Time Environment API.  I am calling a
function called Initialize().  The call is being made and the data
returned properly.  The crazy thing is that I need to return a simple
"true" or "false" but the crazy thing is that once the call
to .getJSON is made, whatever is executing this code (Browser??) is
not waiting for the function call within the .getJSON to complete
which is where the true/false is returned.  Can anyone point me in the
right direction on what terms to search under or suggest how to
rewrite my code?  Thanks so much.

CODE:
//SORM_API is actaully an object.
function SCORM_API() {

  this.Initialize = function() {
    //return true or false

    //example path would be: cdlonline/node/110/scorm_api/Initialize
    var cdlurl = Drupal.settings.basePath + "node/" +
Drupal.settings.company_sco.nid + "/scorm_api/Initialize";

    //The browser doesn't wait for this .getJSON call to finish, it
moves on without it.  Help.  Thanks.
    $.getJSON(cdlurl, function(data){
        //var below becomes the true/false being returned from the
call to cdlurl.
      var Init_ret = data.company_rte_Initialize.ret; //working.
Becomes true or false.
      return Init_ret;  // where does this return to??
    });
   return /*need to return true or false from above .getJSON call but
browser doesn't wait for the above to finish and  I also don't know
how to get the return value from the Init_ret in the above function.*/
  }
}

[Michel Belleville]

In AJAX, AJ = Asynchronous JavaScript
Asynchronous means it does not require the browser to freeze while fetching another resource, which is a good thing because the wait may last for several seconds (even more in more extreme cases). The consequence on JavaScript is AJAX methods does not return the result (that's the point really) and continue past the AJAX call as if nothing happened. The AJAX is detached from the earlier script and loads the content in the background, then triggers callback methods when events like success happened.

So, in your exemple :

...
// previous code executes up to the AJAX call

$.getJSON(cdlurl, function(data) {

// this function is a callback called when the AJAX call succeeds, which is whenever appropriate, and carries the current calling context with it which allows you to give it variables it can reuse

var Init_ret = data.company_rte_Initialize.ret;

// you should do here whatever you want with the data you received.

return Init_ret;
// this returns nowhere in particular, returning anything is not the point of this callback

});

// following code continues immediately regardless on what happens for the AJAX call
...

Michel Belleville

2009/11/4 RayJames <cdlcollege.rayjames@...>

Hi everyone, thanks is advance for your help.

I am working on a getJSON call to my website from a popup window that
is connected through a Run Time Environment API.  I am calling a
function called Initialize().  The call is being made and the data
returned properly.  The crazy thing is that I need to return a simple
"true" or "false" but the crazy thing is that once the call
to .getJSON is made, whatever is executing this code (Browser??) is
not waiting for the function call within the .getJSON to complete
which is where the true/false is returned.  Can anyone point me in the
right direction on what terms to search under or suggest how to
rewrite my code?  Thanks so much.

CODE:
//SORM_API is actaully an object.
function SCORM_API() {

 this.Initialize = function() {
   //return true or false

   //example path would be: cdlonline/node/110/scorm_api/Initialize
   var cdlurl = Drupal.settings.basePath + "node/" +
Drupal.settings.company_sco.nid + "/scorm_api/Initialize";

   //The browser doesn't wait for this .getJSON call to finish, it
moves on without it.  Help.  Thanks.
   $.getJSON(cdlurl, function(data){
       //var below becomes the true/false being returned from the
call to cdlurl.
     var Init_ret = data.company_rte_Initialize.ret; //working.
Becomes true or false.
     return Init_ret;  // where does this return to??
   });
  return /*need to return true or false from above .getJSON call but
browser doesn't wait for the above to finish and  I also don't know
how to get the return value from the Init_ret in the above function.*/
 }
}

[RayJames]

Hi Michel, thanks for that explanation.  I ended up using $.ajax and
setting async to false so it had to wait for the call to complete.
Then I pulled the textResponse out of the ajax call and parsed it with
a json parser script I found on google code.  The thing is that I am
building a SCORM compliant LMS in Drupal and the courses that get
launched need to talk to the LMS through a javascript(jquery) API and
they need feedback after each function call before moving on.  That is
why I had to make the async to false.  Would you or anyone else have a
better idea on how to handle such an interesting problem.  :)  Thanks.

Ray James.

On Nov 5, 7:35 am, Michel Belleville <michel.bellevi...@...>
wrote:

> In AJAX, AJ = Asynchronous JavaScript
> Asynchronous means it does not require the browser to freeze while fetching
> another resource, which is a good thing because the wait may last for
> several seconds (even more in more extreme cases). The consequence on
> JavaScript is AJAX methods does not return the result (that's the point
> really) and continue past the AJAX call as if nothing happened. The AJAX is
> detached from the earlier script and loads the content in the background,
> then triggers callback methods when events like success happened.
>
> So, in your exemple :
>
> ...
> // previous code executes up to the AJAX call
>
> $.getJSON(cdlurl, function(data) {
> // this function is a callback called when the AJAX call succeeds, which is
> whenever appropriate, and carries the current calling context with it which
> allows you to give it variables it can reuse
> var Init_ret = data.company_rte_Initialize.ret;
>
> // you should do here whatever you want with the data you received.
>
> return Init_ret;
> // this returns nowhere in particular, returning anything is not the point
> of this callback
>
> });
>
> // following code continues immediately regardless on what happens for the
> AJAX call
> ...
>
> Michel Belleville
>
> 2009/11/4 RayJames <cdlcollege.rayja...@...>
>
> > Hi everyone, thanks is advance for your help.
>
> > I am working on a getJSON call to my website from a popup window that
> > is connected through a Run Time Environment API.  I am calling a
> > function called Initialize().  The call is being made and the data
> > returned properly.  The crazy thing is that I need to return a simple
> > "true" or "false" but the crazy thing is that once the call
> > to .getJSON is made, whatever is executing this code (Browser??) is
> > not waiting for the function call within the .getJSON to complete
> > which is where the true/false is returned.  Can anyone point me in the
> > right direction on what terms to search under or suggest how to
> > rewrite my code?  Thanks so much.
>
> > CODE:
> > //SORM_API is actaully an object.
> > function SCORM_API() {
>
> >  this.Initialize = function() {
> >    //return true or false
>
> >    //example path would be: cdlonline/node/110/scorm_api/Initialize
> >    var cdlurl = Drupal.settings.basePath + "node/" +
> > Drupal.settings.company_sco.nid + "/scorm_api/Initialize";
>
> >    //The browser doesn't wait for this .getJSON call to finish, it
> > moves on without it.  Help.  Thanks.
> >    $.getJSON(cdlurl, function(data){
> >        //var below becomes the true/false being returned from the
> > call to cdlurl.
> >      var Init_ret = data.company_rte_Initialize.ret; //working.
> > Becomes true or false.
> >      return Init_ret;  // where does this return to??
> >    });
> >   return /*need to return true or false from above .getJSON call but
> > browser doesn't wait for the above to finish and  I also don't know
> > how to get the return value from the Init_ret in the above function.*/
> >  }
> > }

[Michel Belleville]

Are we really talking about the same thing here ? Synchronous in JavaScript here means your page freezes until there's a response to your call. The user can't click anything, hover anything, do anything until the data is fully retrieved and the callback ends. If what you want is just to insure *some* actions are not performed during the call, thus allowing the user to perform other actions while they wait, maybe you should make an asynchronous call and only lock what needs to be locked during the call. To do that, I'd use a simple trick like adding a "waiting" class to the main element where controls should be blocked during the call just before you send your AJAX query, setting a trigger on those elements that prevent their normal action when the "waiting" class is set on their parent, and remove the "waiting" class in the complete callback of the AJAX call. This would insure these controls can't be triggered as long as the call is in progress and that they're released as soon as it finishes, without blocking other actions that could be run in parallel.


Michel Belleville

2009/11/5 RayJames <cdlcollege.rayjames@...>

Hi Michel, thanks for that explanation.  I ended up using $.ajax and
setting async to false so it had to wait for the call to complete.
Then I pulled the textResponse out of the ajax call and parsed it with
a json parser script I found on google code.  The thing is that I am
building a SCORM compliant LMS in Drupal and the courses that get
launched need to talk to the LMS through a javascript(jquery) API and
they need feedback after each function call before moving on.  That is
why I had to make the async to false.  Would you or anyone else have a
better idea on how to handle such an interesting problem.  :)  Thanks.

Ray James.

On Nov 5, 7:35 am, Michel Belleville <michel.bellevi...@...>
wrote:

> In AJAX, AJ = Asynchronous JavaScript
> Asynchronous means it does not require the browser to freeze while fetching
> another resource, which is a good thing because the wait may last for
> several seconds (even more in more extreme cases). The consequence on
> JavaScript is AJAX methods does not return the result (that's the point
> really) and continue past the AJAX call as if nothing happened. The AJAX is
> detached from the earlier script and loads the content in the background,
> then triggers callback methods when events like success happened.
>
> So, in your exemple :
>
> ...
> // previous code executes up to the AJAX call
>
> $.getJSON(cdlurl, function(data) {
> // this function is a callback called when the AJAX call succeeds, which is
> whenever appropriate, and carries the current calling context with it which
> allows you to give it variables it can reuse
> var Init_ret = data.company_rte_Initialize.ret;
>
> // you should do here whatever you want with the data you received.
>
> return Init_ret;
> // this returns nowhere in particular, returning anything is not the point
> of this callback
>
> });
>
> // following code continues immediately regardless on what happens for the
> AJAX call
> ...
>
> Michel Belleville
>

> 2009/11/4 RayJames <cdlcollege.rayja...@...>

>
> > Hi everyone, thanks is advance for your help.
>
> > I am working on a getJSON call to my website from a popup window that
> > is connected through a Run Time Environment API.  I am calling a
> > function called Initialize().  The call is being made and the data
> > returned properly.  The crazy thing is that I need to return a simple
> > "true" or "false" but the crazy thing is that once the call
> > to .getJSON is made, whatever is executing this code (Browser??) is
> > not waiting for the function call within the .getJSON to complete
> > which is where the true/false is returned.  Can anyone point me in the
> > right direction on what terms to search under or suggest how to
> > rewrite my code?  Thanks so much.
>
> > CODE:
> > //SORM_API is actaully an object.
> > function SCORM_API() {
>
> >  this.Initialize = function() {
> >    //return true or false
>
> >    //example path would be: cdlonline/node/110/scorm_api/Initialize
> >    var cdlurl = Drupal.settings.basePath + "node/" +
> > Drupal.settings.company_sco.nid + "/scorm_api/Initialize";
>
> >    //The browser doesn't wait for this .getJSON call to finish, it
> > moves on without it.  Help.  Thanks.
> >    $.getJSON(cdlurl, function(data){
> >        //var below becomes the true/false being returned from the
> > call to cdlurl.
> >      var Init_ret = data.company_rte_Initialize.ret; //working.
> > Becomes true or false.
> >      return Init_ret;  // where does this return to??
> >    });
> >   return /*need to return true or false from above .getJSON call but
> > browser doesn't wait for the above to finish and  I also don't know
> > how to get the return value from the Init_ret in the above function.*/
> >  }
> > }

[RayJames]

Hi Michel, I think I might have confused you a bit.  The user is not
necessarily my concern.  The code running in the background that sends
calls to my api while the user is viewing the course 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.  Every time the course code calls the api the
api is supposed to execute the call and return either data, true/
false, or both.  The problem is that on the Initialize and Terminate
calls, nothing should happen until the api returns a true or false.
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 apologize for not making myself clear enough.  This is
actually a fairly complex system and will be awesome when finished.
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.

Ray James.

On Nov 5, 10:00 am, Michel Belleville <michel.bellevi...@...>
wrote:

> Are we really talking about the same thing here ? Synchronous in JavaScript
> here means your page freezes until there's a response to your call. The user
> can't click anything, hover anything, do anything until the data is fully
> retrieved and the callback ends. If what you want is just to insure *some*
> actions are not performed during the call, thus allowing the user to perform
> other actions while they wait, maybe you should make an asynchronous call
> and only lock what needs to be locked during the call. To do that, I'd use a
> simple trick like adding a "waiting" class to the main element where
> controls should be blocked during the call just before you send your AJAX
> query, setting a trigger on those elements that prevent their normal action
> when the "waiting" class is set on their parent, and remove the "waiting"
> class in the complete callback of the AJAX call. This would insure these
> controls can't be triggered as long as the call is in progress and that
> they're released as soon as it finishes, without blocking other actions that
> could be run in parallel.
>
> Michel Belleville
>
> 2009/11/5 RayJames <cdlcollege.rayja...@...>
>
> > Hi Michel, thanks for that explanation.  I ended up using $.ajax and
> > setting async to false so it had to wait for the call to complete.
> > Then I pulled the textResponse out of the ajax call and parsed it with
> > a json parser script I found on google code.  The thing is that I am
> > building a SCORM compliant LMS in Drupal and the courses that get
> > launched need to talk to the LMS through a javascript(jquery) API and
> > they need feedback after each function call before moving on.  That is
> > why I had to make the async to false.  Would you or anyone else have a
> > better idea on how to handle such an interesting problem.  :)  Thanks.
>
> > Ray James.
>
> > On Nov 5, 7:35 am, Michel Belleville <michel.bellevi...@...>
> > wrote:
> > > In AJAX, AJ = Asynchronous JavaScript
> > > Asynchronous means it does not require the browser to freeze while
> > fetching
> > > another resource, which is a good thing because the wait may last for
> > > several seconds (even more in more extreme cases). The consequence on
> > > JavaScript is AJAX methods does not return the result (that's the point
> > > really) and continue past the AJAX call as if nothing happened. The AJAX
> > is
> > > detached from the earlier script and loads the content in the background,
> > > then triggers callback methods when events like success happened.
>
> > > So, in your exemple :
>
> > > ...
> > > // previous code executes up to the AJAX call
>
> > > $.getJSON(cdlurl, function(data) {
> > > // this function is a callback called when the AJAX call succeeds, which
> > is
> > > whenever appropriate, and carries the current calling context with it
> > which
> > > allows you to give it variables it can reuse
> > > var Init_ret = data.company_rte_Initialize.ret;
>
> > > // you should do here whatever you want with the data you received.
>
> > > return Init_ret;
> > > // this returns nowhere in particular, returning anything is not the
> > point
> > > of this callback
>
> > > });
>
> > > // following code continues immediately regardless on what happens for
> > the
> > > AJAX call
> > > ...
>
> > > Michel Belleville
>
> > > 2009/11/4 RayJames <cdlcollege.rayja...@...>
>
> > > > Hi everyone, thanks is advance for your help.
>
> > > > I am working on a getJSON call to my website from a popup window that
> > > > is connected through a Run Time Environment API.  I am calling a
> > > > function called Initialize().  The call is being made and the data
> > > > returned properly.  The crazy thing is that I need to return a simple
> > > > "true" or "false" but the crazy thing is that once the call
> > > > to .getJSON is made, whatever is executing this code (Browser??) is
> > > > not waiting for the function call within the .getJSON to complete
> > > > which is where the true/false is returned.  Can anyone point me in the
> > > > right direction on what terms to search under or suggest how to
> > > > rewrite my code?  Thanks so much.
>
> > > > CODE:
> > > > //SORM_API is actaully an object.
> > > > function SCORM_API() {
>
> > > >  this.Initialize = function() {
> > > >    //return true or false
>
> > > >    //example path would be: cdlonline/node/110/scorm_api/Initialize
> > > >    var cdlurl = Drupal.settings.basePath + "node/" +
> > > > Drupal.settings.company_sco.nid + "/scorm_api/Initialize";
>
> > > >    //The browser doesn't wait for this .getJSON call to finish, it
> > > > moves on without it.  Help.  Thanks.
> > > >    $.getJSON(cdlurl, function(data){
> > > >        //var below becomes the true/false being returned from the
> > > > call to cdlurl.
> > > >      var Init_ret = data.company_rte_Initialize.ret; //working.
> > > > Becomes true or false.
> > > >      return Init_ret;  // where does this return to??
> > > >    });
> > > >   return /*need to return true or false from above .getJSON call but
> > > > browser doesn't wait for the above to finish and  I also don't know
> > > > how to get the return value from the Init_ret in the above function.*/
> > > >  }
> > > > }

[Michel Belleville]

2009/11/5 RayJames <cdlcollege.rayjames@...>

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 

[RayJames]

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...@...>
wrote:

> 2009/11/5 RayJames <cdlcollege.rayja...@...>
>
> > 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

[Michel Belleville]

As long as you find your way b^^d

Kind regards, and keep us updated.

Michel Belleville

2009/11/6 RayJames <cdlcollege.rayjames@...>

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...@...>
wrote:
> 2009/11/5 RayJames <cdlcollege.rayja...@...>

>
> > 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

[Michael Geary-3]

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.rayjames@...> 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...@...>
wrote:
> 2009/11/5 RayJames <cdlcollege.rayja...@...>

>
> > 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