08.12.05
Is it ready yet?
I’ve been working for the past couple of days to improve our framework for doing partial post-back.
It’s more or less standard AJAX fare, I’m just trying to make it easy to do partial page rendering and replacement that uses our existing ASP.Net control structure.
Works great and was easy to do in Mozilla, but of course Inappropriate Expletive has to make life difficult.
I’ve been trying to make this as resilient to errors as possible. If the AJAX request gets a 400 series error, bail out and try a standard postback. If the server did not send back javascript or gives a 500 series error then print whatever it did get back to the screen.
Replacing the current page with new html in javascript turned out to be more difficult than I expected. According to MSDN you can open the current document, write to it and close it again.
Indeed their sample page does work (in Firefox as well), but when I tried to do the same function through the shell or from the partial postback code it leaves the browser in an inconsistent state at best, and sometimes just crashes it. I ended up clearing the body’s innerHTML, adding an IFrame to the body, and writing everything to that. Not exactly a ‘pretty’ solution.
The communication with the server really needs to be done asynchronously so the browser isn’t blocked while waiting for the server.
With XMLHttpRequest this isn’t to bad.
I’m not as much of a fan of MSXML though. The problem comes from the readyState variable that reports what stage the request is currently on.
From the Mozilla docs:
readonly PRInt32 readyState
The state of the request.
Possible values:
- 0 UNINITIALIZED open() has not been called yet.
- 1 LOADING send() has not been called yet.
- 2 LOADED send() has been called, headers and status are available.
- 3 INTERACTIVE Downloading, responseText holds the partial data.
- 4 COMPLETED Finished with all operations.
That makes sense to me. Once 2 roles around I can start querying the headers to make sure I am getting what I expect. If it was set up to deal with a stream, that could start processing at step 3, and then everything is completely available in step 4.
The only change I could see is that it might be useful to someone to have a stage immediately after the request is sent but no part of the response has been received yet. Not entirely sure where this would be useful though.
It seems that the IE developers felt that this was the most important step though. “I’ve sent a request but don’t have any data back yet.”
From MSDN (parentheses theirs):
- 0 (UNINITIALIZED) The object has been created, but not initialized (the open method has not been called).
- (1) LOADING The object has been created, but the send method has not been called.
- (2) LOADED The send method has been called, but the status and headers are not yet available.
- (3) INTERACTIVE Some data has been received. Calling the responseBody and responseText properties at this state to obtain partial results will return an error, because status and response headers are not fully available.
- (4) COMPLETED All the data has been received, and the complete data is available in the responseBody and responseText properties.
Not only does state 2 implement that, but state 3 is functionally equivalent as well. Since you can’t query any of the headers or even start processing a partial stream in state 3, from my perspective it isn’t really providing anything extra. The only thing worth hooking here is state 4.
Well, there goes my attempt to speed up the processing by doing as much work as possible in the early states while it is still receiving data. Thanks IE.