Attention: We have retired the ASP.NET Community Blogs. Learn more >

Bad Ideas

I've seen this thing[1] going around for a while now, and would like to note that it is an insanely dumb idea (IMO). Basically, the idea is that you override the render method of your web form to output the whole page, and then keep sending javascript blocks to the client to update a progress bar (never returning from render). Not only do you end up generating horrendously invalid html, you also tie up your server's resources while this long running request is executing. Assuming it is intensive because

a) it takes a lot of processing power

or

b) there are a lot of people doing something that requires relatively little processing

This can only lead to problems. In any case, I wrote more about this in the comments on one of the first posts that suggested this solution [2]. Bottom line, do it right, don't do it this way.

[1] http://www.myblogroll.com/Articles/progressbar
[2] http://www.ddconsult.com/blogs/illuminati/archives/000089.html

3 Comments

  • Jesse, I agree with some of the comments you made on my post (which you referenced here), but not others.



    #1. Nobody should really care what the rendered HTML looks like. As long as it's compliant, the end-user is not impacted.

    #2. You DHTML solution works fine, except when you get to cross-browser compatability issues (not all browsers even support DHTML).



    Anyway, the only way to ensure something like this works across all browser types is to stick with standard HTML.



    I've observed a limited performance hit with this technique and anywhere from 1000-5000 concurrent sessions (running ACT scripts on a dual-proc W2K web server). I'm sure that the numbers are a little higher when you hit 100,000+ concurrent sessions.



    Bottom line is that you need to take a look at this solution in the grand scheme of what you're building. It's only wrong if the solution fails (i.e. loading too high, etc). But, keep in mind that DHTML is not the golden egg either. It fails for many of my clients and I have to quickly abandon that kind of design in favor of a cross-browser approach.



    Thanks for letting me post ...

  • Regarding #1, by calling the base render method, then outputting the Javascript tags, you are outputting invalid HTML (ie. your script tags are not found in the head or body tags... I suppose you could tweak the solution to work properly... but, it doesn't as presented). Regarding #2, your solution also requires DHTML, so I don't know what you are meaning by that... I suppose a good way to avoid any DHTML compatibility issue would be to make a Flash based client that handled the status checking. It would still be easy to code (and written in JavaScript, since that is what Flash uses), but would avoid the cross-browser issues.

  • Yes, this is a much better way to do it.

Comments have been disabled for this content.