getJSON - need some direction please.

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.*/
}
}

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 (AT) gmail (DOT) com>

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.*/
}
}

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... (AT) gmail (DOT) com>
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... (AT) gmail (DOT) com

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.*/
*}
}

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 (AT) gmail (DOT) com>

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... (AT) gmail (DOT) com
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... (AT) gmail (DOT) com

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.*/
}
}

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... (AT) gmail (DOT) com>
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... (AT) gmail (DOT) com

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... (AT) gmail (DOT) com
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... (AT) gmail (DOT) com

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..*/
*}
}

2009/11/5 RayJames <cdlcollege.rayjames (AT) gmail (DOT) 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

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... (AT) gmail (DOT) com>
wrote:

2009/11/5 RayJames <cdlcollege.rayja... (AT) gmail (DOT) 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

As long as you find your way b^^d

Kind regards, and keep us updated.

Michel Belleville


2009/11/6 RayJames <cdlcollege.rayjames (AT) gmail (DOT) com>

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... (AT) gmail (DOT) com
wrote:
2009/11/5 RayJames <cdlcollege.rayja... (AT) gmail (DOT) 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

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 (AT) gmail (DOT) 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... (AT) gmail (DOT) com
wrote:
2009/11/5 RayJames <cdlcollege.rayja... (AT) gmail (DOT) 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