How to submit a form using JQuery via AJAX to an ASP.NET and receive the response

The purpose of this article is to showcase how to submit a form to an ASP.NET Page via AJAX using JQuery. Why would we use AJAX to submit a form when developing an ASP.NET application? That is an application design question. However, if it has been decided that AJAX will be used, then JQuery can help you make your codebase smaller and also make the code cross-browser compliant. JQuery does a lot more and for that please feel free to refer to the JQuery site (http://jquery.com/). 

The sample application revolves around accepting some contact details, posting them to an ASP.NET form and then displaying the data received by the server. The sample code can be downloaded from the following zip. 

Source:  contactmanagement.zip 

Solution Screenshot 

Steps

1.  The first step will be to get the uncompressed version of JQuery script file. The file can be downloaded from http://code.google.com/p/jqueryjs/downloads/detail?name=jquery-1.3.2.js&downloadBtn=

2.  Next, create a default asp.net website and rename default.aspx to “SaveContact.aspx”

3.  You may also have to add a web.config file from add new items as in VS 2005, it may not add by default for a website

4.  Open “SaveContact.aspx” in the designer and remove all the HTML tags (see screenshot) 

5.  Add default.htm and include the jquery script file and create the form shown in the code snippet (see screenshot) 

6.  Now add the jquery function to submit the form and receive the results as shown in the code snippet (see screenshot) 

7.  $() represents the JQuery object

8.  The $(document).ready() ensures that no javascript is executed till the page is ready with all the dom elements loaded

9.  $("#submit_btn").click() searches for an element with ID as submit_btn and adds a function to the click event

10. $.post expects 3 arguments

a.       The name of the page to which the form will be posted

b.      The arguments which need to be posted

c.       The function to be called on receiving the response

11.   The return false ensure that the there is no page refresh after the call is completed

12.   Response contains the entire HTML output of SaveContact.aspx

13.   Here we have taken the response set it to the inner HTML of a DIV using $("#DivResult").html(response).show()

14.   # is the keyword used to refer to a the ID of an element.

15.   .html() is a function in JQuery to update the inner HTML. You can also use the same function to get the inner HTML.

16.   Show() causes the div to be displayed immediately, even if it is hidden. This is particularly useful if you keep your div hidden by default.

17.   On the code behind of SaveContact.aspx, add the code in the screenshot 

18.   While it is quite possible to save the received result into a database writing simple ADO.NET code, the purpose of this article was to keep focus on the core aspect, i.e., showcase how we can bring the data and submit a response

19.   Given below is the screen shot of a sample input and output generated from the code. Please feel free to try any other data too. 

The application has been tried on IE7, Firefox 2+ and Chrome 1+. Barring a few discrepancies in the UI, the functionality is the same in all 3 browsers.

Recommended strategy for handling exceptions in dot net applications

Purpose of this article 

1. Take advantage of the good exception handling practices
2. To provide a structured approach in handling exceptions

 

There is a significant amount of debate in my workplace about how much of exception handling is enough and what really should be the scope of exception handling. Without getting into the debate myself, I am going to present my views on the scope, benefits, drawbacks and the most appropriate way of handling exceptions in dot net projects. 

Scope 

Exceptions are not expected to occur but are known to happen when either there is a flaw in the coding or the system has received data it is not equipped to handle. Professed exceptions that are raised within code due to foreseen circumstances such as, duplicate record entry, etc should not stop the program execution. The user should be displayed an appropriate warning message and allowed to take corrective action. The true exceptions should be, 

1. Logged at the first occurrence location into a log file
2. A new custom exception with only those exception details that may be used within the code and the exception class inheriting from ApplicationException should be created and rethrown.
3. This custom exception should be caught and rethrown across all levels till we reach an event handling method (e.g.: catch(CustomException) { throw; }.
4. The user should be redirected to an error page which displays some summary details of the exception and any standard message to the user that may suit the need of the application.
5. The same error page could allow the user to bring this exception to the notice of a designated authority (maybe a web admin) via email created in a rich text environment (also allowing snapshots to be attached). This is important if the exception can keep occurring every time the user revisits the involved activity keep the user from carrying on with his / her tasks. However, this may be more useful in the case of intranet applications. Public portals could cause a deluge!

 

Details that should go into an Exception and its message

Typically, there are two kinds of exceptions that will occur. The first kind is thrown by the system and the second kind is thrown from the code. In the former case,, post logging, you should replace it with your own exception object (inheriting from ApplicationException class). 

In the case of your wanting to throw an exception, the message should contain the following information, 

1. The method name which first caught / invoked the exception.
2. The class name (whether it’s a web page or windows form or a library class) which contains the method mentioned in point 1.
3. Some details of the cause of exception / the activity that has been affected by this exception.

 Additional information may be provided as per the application requirements. 

Proposed Framework for Exception Handling in an Application

1. Catch and throw exceptions as proposed in the above sections
2. Log the exception to a log file the first time it is caught
3. Display a user expectation friendly error page when exceptions occur giving the facilities mentioned above
4. Run a background service that periodically clears the log file entries and transfers them to a database for analysis of application state. Alternatively, you can log the exceptions to a database straight away and keep the log file as a backup plan incase the database is unresponsive.

 Footnote 

The details mentioned so far are more with respect to dot net (c#, vb.net, asp.net) applications and specific applications, especially scientific or time critical applications may require a different approach to exception handling. I am sure that there may be scenarios / options / issues that have not been mentioned explicitly in this article. Anyone contributing to this article would be appreciated. I am also more than willing to provide further information on specific questions.