Tales from the Evil Empire

Bertrand Le Roy's blog

News


Bertrand Le Roy

BoudinFatal's Gamercard

Tales from the Evil Empire - Blogged

Blogs I read

My other stuff

Archives

June 2005 - Posts

Atlas project announced

Scott Guthrie announced the Atlas project in a recent blog post. The Atlas project aims at considerably simplifying and enriching the client script development experience. It includes but is not limited to AJAX/callbacks and cross-browser client-side declarative binding of elements and behaviors. One of our goals is to leverage the experience of client-side programming that exists inside Microsoft (see Outlook Web Access, MSN Spaces, MSN Virtual Earth, etc.) and give easy access to that technology to developers.

Nikhil also blogged about this here.

Here are the first press articles on the announcement:
http://news.com.com/Microsoft+gets+hip+to+AJAX/2100-1007_3-5765197.html?tag=nefd.top
http://www.eweek.com/article2/0,1759,1832233,00.asp
http://www.infoworld.com/article/05/06/28/HNatlasframework_1.html
http://www.theserverside.net/news/thread.tss?thread_id=34897
http://www.internetnews.com/dev-news/article.php/3527226

Fun with callbacks Part 4: what about postback events?

One thing that's certainly not that clear enough about callbacks is what happens with regular postback events and control state. During a callback, we reconstruct the state of the page as it was during the last postback. The reason we are doing this is that we want the logic in the callback method to be able to access the rest of the page with controls in the right state.

We don't update the ViewState during a callback because we allow for parallel callbacks (by the way, don't let the "useAsync" parameter of GetCallbackEventReference fool you: it's really about parallel or sequential). If we had both parallel callbacks and ViewState updating, the page would easily get to an inconsistent state. What control developers do to work around this problem is to store the client-side and callback state changes for their control in a separate hidden field and replay these changes server-side on the next postback. This adds a little complexity to controls such as the TreeView.

But how are we maintaining the last postback state during callbacks? One of the first things the WebForms client script does in a callback page is to initialize an object and store the contents of the form in it, before it can be modified. This object will be sent back to the server with the callback parameters. It means that your network payload is more important than just your parameters but that's the price of statefulness (more on this later). When we receive the callback server-side, this enables us to reconstruct the state of the page as it was during the last postback (which is the last consistent state we know). We don't want the actual state of the form at the time the callback was made because this state might be inconsistent (because of validated fields and so on). If you want a perfectly up-to-date version of a form field (and not just state data), it means that it is really a parameter of your callback and should be transmitted as such.

I know this needs a little getting used to (I needed it myself), but it also raises a question: if the state is reconstructed exactly like it was during the last postback, and if an event (for example a click event or a textbox change event) happened during the last postback, will this event be re-triggered on each callback?

The answer is no. To trigger a click event, depending on the button being a regular button, an image button or a link button, we look at the form field for this button or at a special hidden field pair. Both of these are stateless, which means that even if their value is non-empty during the server postback, once they get back to the client, they are empty again. Thus, when we send the initial form state during a callback, these fields will be empty and the event will not be triggered again. For a textbox change event, it's a little different. The change event compares the actual value of the form field with the last value it stored in ViewState. During a callback, we get the initial value, which is identical to the value in ViewState because the latter was stored at the end of the last postback, after change events. So no change event, except if you disabled ViewState (but it's the same thing with postbacks). Which is one more reason why we don't want the updated value of the field at this time: we don't want the change event to be triggered during every callback until the next postback.

Previous episodes: Part 1, Part 2, Part 3

Die, marker! Die!

Did you ever notice how people can't ever throw a marker away? How many times have you seen this scene?

Guy goes to the whiteboard. Guy picks up a marker and tries to write with it, but the marker is dead. What does guy do? Does he throw the marker away? No, he doesn't! He puts it back in the little gutter under the board and picks up another one, which is also dead, and so on...

More Posts