In my last post, I pointed out some of the problems with AJAX. In this post, I'll show you to take the ASP.NET GridView control and AJAX-enable it in about 30 seconds using Microsoft's new Atlas framework.

The GridView control is one of the most powerful and commonly used components of the .NET framework. With it, we can easily display data from a datasource such as SQL Server and enable things like sorting, editing, paging, and deleting. All of this can be done with little or no code. Every time you execute a GridView function (such as switching pages) a postback occurs and the entire page reloads. Wouldn't it be great if we could update the GridView dynamically without the need for a postback every time?

The Atlas framework makes this not only possible, but extremely simple.

Step 1 – Download and install the Atlas Framework

Step 2 – Create a new Atlas project and make a new web form with a GridView control bound to a datasource. The Northwind database will work well for this.

Step 3 – Add an Atlas ScriptManager Control to the page and enable partial rendering.

<atlas:ScriptManager ID="ScriptManager1" runat="server" EnablePartialRendering="True" />

Step 4 – Surround your GridView control with an Atlas UpdatePanel conrol.

<atlas:UpdatePanel ID="UpdatePanel1" runat="server">
   <ContentTemplate>
      <asp:GridView ID="GridView1" runat="server" ... />
   </ContentTemplate>
</atlas:UpdatePanel>

Step 5 – Save it. Run it. Marvel at how simple that was.

Permalink | Posted On May 31, 2006 Comments (4) | TrackBacks (0)

AJAX is the latest industry buzz-word and to hear people talk you'd think it'd have to be the best thing since sliced bread. I'll go on record as saying that I think AJAX is awesome but, since every other article touts how amazing it is, I'd like to play devil's advocate and point out a few of it's flaws.

JavaScript - AJAX functions entirely by using lots of client-side JavaScript to send requests to the server and update data on the page. No JavaScript means that none of your cool functionality works at all. Providing a non-AJAX alternative may require a lot of extra work.

The Back Button - This is fairly similar to what happens with Flash sites. The user does something, does something else, then wants to return to the previous task so they click the back button. When you're serving normal HTML pages this works great. In an AJAX application however, the back button is essentially rendered useless.

Analytics - Having standard HTML pages provides an easily mechanism to track what your users are doing. AJAX slightly complicates this by replacing some of the pages with asynchronous JavaScript calls. While not impossible, it does have the potential to add a layer of complexity to capturing analytical data. I should note however, that there are companies such as Crazy Egg that are actively working to solve this problem.

Accessibility - Having pages that rely heavily on JavaScript and updating dynamically has the potential to wreak havoc on screen reader type programs for users with visual impairments.

Search Engine Optimization - At this time it may be difficult for search spiders to properly index content returned through complex AJAX updates.

Pasting a Link - The page updates frequently but the address bar never changes. When you cut and paste the link to your buddy, they just see the homepage instead of the info you intended. (Google Maps solves this nicely with a 'Link to this Page' button that updates the URL)

I'm certainly not trying to discourage AJAX use as none of these issues is insurmountable. As with all new technologies however, I would encourage caution and careful consideration before deploying. It's important to understand why you're using the technology instead of using it just to brag that you built an AJAX site. Remember when everyone had to have an all-Flash site, or crazy DHTML? That was the cool thing to do but people quickly learned that it wasn't always the right thing to do. I would urge people to remember that lesson and use the same caution here. AJAX is a fantastic technology and can be greatly beneficial when used properly. Let's do our best to ensure that it stays that way.

I'm out of town for a few days but after that I'll be back with some code samples on how to do some pretty neat things using ASP.NET 2.0 and Atlas.

Permalink | Posted On May 18, 2006 Comments (4) | TrackBacks (1)

Anyone reading this blog most likely knows what RSS is. I love RSS and subscribe to dozens of feeds, many of which I don't even have time to read. Not everyone is as quick to jump on the bandwagon however. Many users still stick to browsing the web and checking their email as their primary internet activities. For those non-RSS users, sending an email to alert them of new content is often a great way to encourage repeat traffic.

Maintaining a site and sending out email newsletters just seemed like too much work to me. Recently I found a great solution to this problem in the form of Squeet.com. Squeet is an online service which allows users to subscribe to an RSS feed and have it delivered to them via email. It's easy to setup and best of all free.

I've added it to Code Scene (in the right navigation bar) so anyone who wants to can be notified by email whenever I post something new; a "live" subscription. For sites that update a lot more frequently, you can opt for a daily or weekly subscription to catch up on the new content.

Being that it's free and easy to setup, I think this is a great service to offer to your users.

Find out more about Squeet.com

Permalink | Posted On May 13, 2006 Comments (0) | TrackBacks (0)

My original article on Content Management Systems has sparked some debate and some keen observations so I'm posting some follow-up thoughts.

First off, I really don't hate all CMS tools. I think that when used properly they can be very good at doing what they're designed for.. and that is to manage content. That's a very important distinction to make. A CMS is not a design tool. It's not an architecture tool. It's sole purpose is to manage the content of your site.

What's more important though, is who is managing the content. If the person in charge is a web developer then a CMS or a blogging platform such as MovableType can be a tremendous asset to help alleviate some very tedious production work. However, when the CMS is being used by client who's not a web developer, that's when the problems arise. People who aren't trained web developers simply don't know the best practices for managing a website.

• Copy and Pasting from Microsoft Word into many CMS tools results in horribly mangled HTML/CSS code
• Uploaded images and PDFs aren't properly compressed for the web
• Title tags are often forgotten
• Often times copy isn't written properly for the web or for Search Engine Optimization (SEO)
• Semantic h1-h7 header tags are rarely used which can also hurt SEO
• Accessibility attributes such as alt tags are forgotten or improperly used. I've seen a CMS insert things like alt="img0006.gif" which is NOT a proper alt tag.
• Etc, etc, etc

My whole point in this tirade is that the web isn't a DIY project anymore. Just because you read a book on HTML a few years ago doesn't make you a web developer, sorry.

If you want your car properly maintained, you go to a mechanic... your health, a doctor... your house, a roofer or a plumber perhaps. If you want your website properly maintained, hire a web developer to do it and let them chose whatever tools they think is best.

Permalink | Posted On May 6, 2006 Comments (1) | TrackBacks (0)