I recently found myself needing to perform a bit of client-side page initialization, both on initial page load and when partial postbacks completed. I muddled through by using window.OnLoad() for the initial page load and an EndRequest handler for partial postbacks. It worked, but I wasn’t very happy with the kludgey nature of it.

On an unrelated ASP.NET forums thread around the same time, Steve Marx pointed out to me that the AJAX framework automatically wires up any client-side function named pageLoad() as an Application.Load handler. It’s actually in the docs, if you dig for it:

To handle the load and unload events of the Application object, you do not have to explicitly bind a handler to the event. Instead, you can create functions that use the reserved names pageLoad and pageUnload.

Click here to read the rest of this post »

YSlow, Yahoo’s previously internal-only HTTP profiling tool, has been released to the public. It extends FireBug to analyze a page and provide an optimization checklist.

After experimenting with it for a bit today, I think it will quickly become as integral to my performance tuning as FireBug itself.

Get it here: http://developer.yahoo.com/yslow/

I’ve recently noticed the real-time “spy” feature popping up on more and more sites. Though it’s often a huge time waster, I can’t help but love the feature. It’s a great example of AJAX leveraged to do what it does best. It struck me that an ASP.NET AJAX implementation would be an excellent use of page methods for efficiency and __doPostBack() to trigger an UpdatePanel refresh. So, I decided to put together a proof of concept, using the ASP.NET AJAX framework.

To create a fully functional example, several things need to be done:

• Choose a data source to “spy” on.
• Build an interface to add rows, for testing.
• Display that data in a row-based format.
• Create a method to find the most recent row of data.
• Use that method to asynchronously monitor row updates.
• Refresh stale data when additions are detected.

Click here to read the rest of this post »

If you’ve done much ASP.NET AJAX development, you’re no doubt familiar with JavaScript alert errors similar to the one pictured above. This particular one occurs on the official ASP.NET forums in FireFox, if you try to navigate away from viewing a user profile before the Recommended Reading panels asynchronously load.

Not only is the error message of “…” completely meaningless, but it blocks your intended navigation away from the page until you’ve dismissed the alert window. Hopefully, someone at Telligent will read this, because the ASP.NET AJAX framework gives us an easy way to replace the annoying JavaScript alerts and vastly improve the usability of our applications.

Click here to read the rest of this post »

I’ve noticed a lot of discussion lately regarding methods to refresh an UpdatePanel via client script. This is very easy on the server side, of course. You can just call UpdatePanel.Update(). However, on the client side, the most common solutions I’ve been seeing just don’t feel right.

Many will advise you to use a hidden button control inside the UpdatePanel, manipulated via button.click(), to trigger a partial postback of the UpdatePanel. While it does work, I never have been able to get past the kludgey nature of that solution.

Click here to read the rest of this post »

If you’re like me, it’s hard to resist the lure of tossing a half dozen UpdatePanels on every page and reveling in AJAX goodness. The UpdatePanel makes AJAX trivially easy for anyone to implement, even without knowledge of what’s actually going on behind the scenes.

Unfortunately, that very lack of transparency regarding the mechanics of the client/server exchange makes it all too easy to shoot yourself (or your application) in the foot. Let me give you an example that you’re probably familiar with by now, and thoroughly sick of seeing:

Click here to read the rest of this post »

This is a follow-up post, building on the foundation laid in ASP.NET AJAX username availability check. In this post, I assume you’ve read and understood the first post.

After originally implementing AJAX username availability checking in my applications, I noticed an edge case scenario that replayed itself too often to ignore. The availability check could potentially take longer than a particularly fast user would need to complete the form. To avoid any trouble in that scenario, I wanted to add a progress indicator to the checking process and disable the submit button’s until an available username was selected.

Click here to read the rest of this post »

I would truly like to thank whoever submitted AJAX username availability check to Ajax Rain yesterday, for introducing me to this great resource. Until seeing it as a referrer in my stats, I was unfamiliar with the site. After taking a look today, it appears to be an absolute goldmine of client side ideas.

If you’re interested in AJAX development of any kind, check it out. Its RSS feed is definitely a permanent addition to my Google Reader.

When you have a name as common as mine, you run across the entire gamut of schemes to deal with username availability in membership systems. By availability, of course I mean denial and rejection. Out of all of the ways that I’ve had “Dave” rejected, inline AJAX verification is definitely the least annoying. Wanting to be less-annoying myself, I’ve added the same functionality to my ASP.NET AJAX sites. Let me show you how I did it.

Click here to read the rest of this post »

Use Response.Write().

If you’re worried that might not bring your website to its knees reliably enough, be especially sure to use Response.Write in code that’s executed during partial postbacks. It’s that easy!

Emitting JavaScript probably comprises the vast majority of Response.Write uses in ASP.NET projects today. So for our purposes, let’s say that we really want to display a JavaScript alert window during a partial postback, from code behind. Using Response.Write, this is how the task would have been accomplished:

Click here to read the rest of this post »