19. April 2010 11:07
Just a short little post, I do intend to followup my last post with a post with code on combining/minifying your JavaScript and CSS, this just caught my attention, and wanted to mention it.
In the process of doing some technical screenings, it is really suprising how many people don't understand or even know about the HttpContext Items Collection in ASP.Net. Essentially, if you have any point in a request lifecycle, you need to store information to be consumed at another point, the HttpContext Items is probably at least a strong consideration of where to put that object. In the past, I've launched several worker threads in the Page Load event, that will put their data into the HttpContext Current once they are done, for use within the controls on a page... in the PreRender, I'll wait for each of those threads to finish their work. This is helpful for those times when you have multiple remote resources to acquire information from in order to be used within a page. Since most of the time is spent waiting on remote resources, it's better to run them all at once, vs. running them in serial. In parallel, the request(s) will take slightly longer than the longest request. In serial, it would take the sum of all the remote requests.
I've also used the Context.Items to store a reference to a script object that will build a collection of scripts to be included within a page (at the bottom), so that each control can reference the scripts it needs included. I'm now using a different technique for most of the web applications I am working on, just the same it's worth knowing.
Many developers I've seen coming from the Java world will attach items to the current thread. This is dangerous in the scope of an ASP.Net application, as each event in the ASP.Net request lifecycle isn't guaranteed to run under the same thread, and in fact under load, may well not. This can lead to data leaking out of the intended scope, where HttpContext's Items collection will carry forward with the request lifecycle.