The ASP.NET Diet Part 2 ' Making a Thin Contact Form

Back in January I wrote about making a thin contact form in an effort to demonstrate how to make ASP.NET forms lighter and much more user responsive. The key to making the form more responsive was to avoid using the WebForm and UpdatePanel conventions. I demonstrated how to leverage ASP.NET AJAX without the UpdatePanel to introduce some nice user interactions and reduce payloads.

ASP.NET AJAX's unique position is its ability to interact with ASP.NET Web Controls. To do this is produces a pretty heavy client-side payload or code that is sent from the server to the client. Often the payload cannot be cached on the client because it is dynamically generated, causing JavaScript files to be downloaded on each request and a lot of unnecessary JavaScript to be emitted in the HTML markup, a very bad practice.

The second part of the first tutorial demonstrated how to accomplish the same feat without the UpdatePanel. This really helped reduce request payload with a good user experience. But I was still not happy, there is still a lot of extra code generated because of the ASP.NET AJAX framework and the ScriptManager. Plus each round trip to the server using the UpdatePanel has to send and receive the entire ViewState.

jQuery As you can tell I am still not satisfied with the results, so lets press it further. Unless you are under a rock or buried deep in a corporate cubicle completing TPS reports you have at least heard of jQuery. Where ASP.NET AJAX is a top notch AJAX framework for ASP.NET WebForms to leverage, jQuery is, what I consider safe to say, the king of AJAX frameworks. It is super easy to work with, there is a great community of resources available around it and it works great with ASP.NET.

There are numerous Plugin libraries available for jQuery. In this tutorial I am going to work with the jQuery Form Plugin. The jQuery Form Plugin makes it really easy to manage the form submit process. The way it works is you setup or assign the form's submit action to be handled by the plugin. For this example I am going to simply copy the HTML from the ThisContactForm.aspx and place it in the jQueryContact.aspx page. (note: I cleaned up the intro text on both forms to make it a little shorter ;).

So the DIV elements will remain the same. Each of the INPUT fields has their id attribute changed to name, which is the normal attribute to use for a form. You can still use the id attribute, but it is not needed in this example. What does change is how the submit action is handled. In the previous page the Submit button assigns a JavaScript method to the onclick event. With the jQuery Form plugin you instead set the submit action in the JavaScript. I am not going to get into the details of how to work with jQuery in this tutorial, but there are a few things to understand. With ASP.NET AJAX to get a reference to a DOM element you use the $get function, with jQuery you use $(). In the previous example I used the HideElement and the ShowElement functions, jQuery has built in methods; hide() and show().

The jQuery Form Plugin adds the ajaxSubmit method, which accepts a series of 'settings' that define how the submission process works. In this example I set the 'url' property to the URL of a generic handler, not a web service. While you can post to a web service I found it cumbersome for this simple process, again another post if forthcoming. I found that using a generic handler was a quick and dirty way to solve the issue. The 'success' property is set to a function and accepts a result parameter.





() { $(


).hide(); $(



// submit the form



).ajaxSubmit({ url:


, success:


(result) { $(


).hide(); $(


).show(); alert(result); } });

The ajaxSubmit method will automagically serialize the form's values to POST data that is POSTED to the Handler. The Handler then processes and returns a good or bad response. The handler receives the data, you can then retrieve it using the Request.Form call to a ContactInfo object and returns either 'good' or 'bad'. Of course I am not doing any real work here, just simulating it again.









IHttpHandler.ProcessRequest context.Response.ContentType =






ContactInfo lContactInfo.FirstName = context.Request.Form(


) lContactInfo.LastName = context.Request.Form(


) lContactInfo.Address1 = context.Request.Form(


) lContactInfo.Address2 = context.Request.Form(


) lContactInfo.City = context.Request.Form(


) lContactInfo.State = context.Request.Form(


) lContactInfo.Zip = context.Request.Form(


) lContactInfo.Phone = context.Request.Form(


) lContactInfo.EMail = context.Request.Form(


) lContactInfo.Request = context.Request.Form(




'Do something here.....

Threading.Thread.Sleep(1000) context.Response.Write(


+ Environment.NewLine)




Exception context.Response.Write(


+ Environment.NewLine)





For this demo I decided to just return 'good' or 'bad' to indicate submission success. When the handler returns, the page will update to let the user know their request was received. So lets do a little visual compare with Fiddler one more time.

First the ThinContact form from the previous example:

There are 6 files or resources downloaded totaling 99339 Kbs. The page itself is 5,894 Kbs, which is not a ton, but there are 4 JavaScript file downloaded for ASP.NET AJAX that account for a lot of the request. Granted these files should be cached on the client, but the reality is ASP.NET AJAX dynamically serves the JS content based on what it thinks is needed on the page. So the optimization caching gives you is lost.

Now for the new jQueryForm:

Now we are talking, 4 resources, totaling 84,939 Kbs. The page itself is smaller, as is the jQueryContact.js file. Additionally there are two jQuery .js files downloaded that are cached the first time they are retrieved on the client. So this is a big savings.

Notice how little there is involved in building the page. There are only three references to JavaScript files. In fact you could combine all the plugin and local site code into a single file if you wanted to do so and reference the actual jQuery file from a public host, like Google,

The real measure is in how many bytes are sent across the wire to and from the client. As you can see it is not much and the reaction on the client is really fast.

Share This Article With Your Friends!

We use cookies to give you the best experience possible. By continuing, we'll assume you're cool with our cookie policy.

Install Love2Dev for quick, easy access from your homescreen or start menu.

Googles Ads Facebook Pixel Bing Pixel LinkedIn Pixel