Why no synchronous call support in Atlas?

Thursday, December 1, 2005

Synchronous calls are easy to do, it's just one boolean property to set to true in the XmlHttp object. I'm not saying that it is hard or impossible, just that it is a very bad idea to use synchronous calls because the chances that you're going to block the browser (and have to kill it using the task manager) are just too high. Even if the network worked perfectly, it would still make the general responsiveness of the application worse than necessary. If that's really what you want, you don't have to use our network stack. You can very well build an Atlas application that makes its own synchronous XmlHttp calls instead.
Asynchronous code does in no way force you to write unclean code or store your context in page-level variables. The Atlas source code shows that almost the only page-level variables that you need are the namespaces. You can use Function.createDelegate and Function.createCallback to create references to functions without the need to have global variables. These methods are using closures internally to get this result. Here's an example:

_keyDownHandler = Function.createDelegate(this, this.onKeyDown);

Here, I'm setting the private variable _keyDownHandler (a private variable is a variable declared inside the body of a function/class) to point to the onKeyDown class method. When the delegate is called, it will run within the context of the particular instance that created it and will have access to all its instance properties and methods. Hence, there is no need for global variables. createCallback similarly enables you to create a reference to a function that will remember the arbitrary context object you passed it at creation-time when it is finally called.
If you need to know the result of the call before allowing the user to continue, you shouldn't block the whole browser. What you should do is disable the pieces of UI that should remain untouched while the call is going on (which means other parts of your app can continue to run in the meantime) and re-enable them when the call completes. You can see an example of how to do this declaratively in this blog post:
http://weblogs.asp.net/bleroy/archive/2005/09/20/425698.aspx
Asynchronous calls actually become very natural and transparent in a declarative and event-driven environment such as Atlas is providing.
You may think asynchronous calls are more difficult, but unfortunately until the browsers become multitasking scripting environments (which is not something likely to happen in the foreseeable future imho), they are the only way to create a responsive client web application.

No Comments