Recently, I’ve been working with applications that require very few postbacks. While this has been great from a usability perspective, after all the application is very ajaxy and responsive, it’s caused some unexpected problems. One problem that it caused is that ASP.NET Sessions were expiring even though the user was actively using the application.
The Sessions were expiring because the user wasn’t causing a postback (full or partial) and thus executing the ASP.NET page life cycle, which takes care of maintaining Session for us by implementing the IRequireSessionState interface.
One way I could have solved this problem is to rehydrate Session whenever an Ajax request was received (such as by marking the web method as requiring Session), but this is a bad programming practice for a few reasons. First, having Session attached to a request and response isn’t very RESTful and breaks at least a couple of design rules. Second, it’s a relatively expensive operation to pull Session from the session store, deserialize it into the Session object, use it, maybe modify it, and then serialize it back out to the Session store when the request is complete. As Session gets bigger, this operation gets more expensive and I really want the Ajax features of the application to fly. Finally, I might not own the REST endpoints that I’m using for my application’s functionality. In that case, I’m talking to a third party service (i.e. Amazon’s S3 service), and not communicating at all with my application, but I still need to keep Session alive. The user doesn’t know or care that I’m talking to Amazon. They just think they’re using my application.
What I really wanted to do was sometimes revalidate Session while the user interacted with the Ajaxy parts of the application without the user paying any perceivable performance penalty and not breaking too many rules of application design.
Download the text version of the changes
In a past post, I highlighted a problem with the method ASP.NET AJAX uses to determine if the DOM is ready to be modified. (Other developers have since commented that they’ve seen this problem in the wild.) I followed that post with another one where I provided code changes to fix the problem. Through comments on that post, talking with other developers, and reading other people’s blogs, I determined that it was a little bit unelegant and didn’t take into account all situations.
Dave Ward of Encosia.com has setup a control writing contest where you can win one of three free copies of Adam and my book Advanced ASP.NET AJAX Server Controls for .NET Framework 3.5. (Next time, I’m definitely coming up with a shorter title!) Adam and I are going to be judging along with Dave and there are many ways to win so hop over to his site, read the post, and write some code (or documentation)!
Good luck and thanks for putting it together Dave!
12/15/2008 – Two things to update:
First, sources at Microsoft confirmed this bug for me and said that a fix was already completed for v-next. I’m not sure when the next release will take place; if it will be with VS 2010 or sometime earlier, but they have it fixed.
Second, Jason Kealey has a fix that is less intrusive than the one I suggested here. You can find it here
Since the rest of the tech-world is talking about and trying Google Chrome, I thought that I’d give it a whirl and see how it interacted with ASP.NET AJAX. I’ve worked on a couple of ASP.NET AJAX applications for work (including a public website: http://showcase.costar.com) and have a bunch of small test application that I’ve written for other purposes and was curious to see how those held up when accessed with Chrome. For the most part, with the smaller applications the browser worked as expected. I had almost no layout issues (as we program for IE6, IE7, FF2, and FF3) and almost no JS problems. But, when I ran ShowCase, which uses UpdatePanels to load large swathes of a page and in doing so loads external scripts dynamically, the application broke when accessing the mapping portion of the application. Since I was responsible for this part of the application, I needed to investigate further.
Dave Ward, of the site Encosia.com, has put together a great, well-written review of our book, Advanced ASP.NET AJAX Server Controls.
Thx again Dave for the nice review.
Note: Below the following little story, there’s a work around that I came up with so if you’re looking for help, jump down a bit.
A story of despair. Here’s how my evening went.
Act I Scene I: I just downloaded and installed the Visual Studio 2008 SP1 / 3.5 SP1 and I’m excited to take a look at how to use the Script Combining mechanism. I’ve been using the ToolScriptManager’s script combining ability for a while now, and while it is okay, it has its quirks and I was hoping the one in .NET 3.5 SP1 would be better.
Act I Scene II: I notice that the ScriptManager has a new templated section called CompositeScript. This is the spot I need to investigate closer.
We all make mistakes, some are just published in books.
The format strings that are allowed for Number types are the following:
- c or C: Currency
- p or P: Percentage
- d or D“: Decimal (# number of digits)
- n or N“: Numeric (# number of digits after decimal)
– e, f, g, r, x, and custom format strings are not supported
The standard format strings that are allowed for the Date type are the following:
- d: Short date pattern
- D: Long date pattern
- t: Short time pattern
- T: Long time pattern
- F: Full date/time pattern (long time)
- m or M: Month day pattern
- s: Sortable date/time pattern
- y or Y: Year month pattern
– the standard format strings: f, F, g, G, O, o, R, r, u, U are not supported. However, custom format strings that use the “mmm”, “yyyy”, “hh”, etc. formats are supported. You can build your own date format string.