RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Detect Web Form Field Changes in ASP.NET : Page 3

Although .NET 2.0 has been released, many applications are still running under .NET 1.x. The technique presented in this article is based on .NET 1.x, but you can easily port it to .NET 2.0.

A Couple of Demonstrations
To illustrate this technique I'll create a simple Web Form called TestChange.aspx. Users can edit this form and then submit form data. The page will then display the IDs of all changed form fields, as shown in Figure 1. A Panel control serves as the container of all form fields. The code calls the FindChangedFormGroupFields in the Submit button's Click event to extract the IDs of the changed form fields.

If you change some fields and submit the form, it will display the IDs of changed fields in red. After you click Submit, nothing is immediately shown since no change takes place at this time. In the subsequent two sections I will provide pseudocode for two sample applications. One will update form data upon change. The other will build a SQL UPDATE statement on the fly. You can easily apply the skills I present in this article to enterprise Web applications to increase performance and enrich the flow of your Web sites.

Figure 1: This simple Web page vividly reveals how a change of form field is detected.
Application 1: Update Changed Form Data
Consider an iterative control such as a Repeater that contains multiple groups of form fields; each RepeaterItem serves as the container for one group of form fields. You bind a FormGroup to the first server control within a repeater item (which might be an invisible Literal if your user does not need to see it). Listing 2 shows how to iterate through a Repeater to update a changed group of form fields within RepeaterItems.

Application 2: Build a Dynamic SQL UPDATE Statement
If a group of form fields corresponds to a data table record, you can build a dynamic SQL UPDATE statement based on change information from the data fields. To make this work, you need to know the name, the SQL type, and the value for each query parameter. For simplicity, assume the control ID for each control is the same as the parameter name. Next, add two other properties, SqlType and SqlValue, to the common interface to supply the SQL parameter type and value. The code below shows how to build a SQL UPDATE statement using SqlParameter. You can discover the parameter names and types via reflection, but you cannot build a dynamic SQL UPDATE statement without knowing which field(s) have changed.

   'Build Sql update statement according to table name, and column 
   'names (changed form fields)
   ''' UPDATE tableName SET column1=@column1, column2=@column2 
   ''' WHERE keyColumn1=@keyColumn1 AND keyColumn2=@keyColumn2
   'Build Sql Parameter, suppose ifg is type of IFormGroup
   ''' SqlParameter aParam= new SqlParameter("@" & columnName, 
   ''' ifg.SqlTtype)
   ''' aParam.Value = ifg.SqlValue
You can easily apply the skills I present in this article to enterprise Web applications so as to increase performance and enrich the flow of your Web sites.
Some developers may argue that embedded SQL may hurt performance compared with stored procedures. Updating all columns of a table record using embedded SQL or stored procedures may incur an unnecessary database retrieval to restore state upon page postback, and updating many columns using stored procedure may also decrease performance compared to updating only few changed columns using a dynamically-built embedded SQL UPDATE statement. Without a doubt, dynamically built embedded SQL will improve performance if you only use embedded SQL. You must choose whether to use embedded SQL or stored procedures.

This article presents a reliable and effective server-side technique to detect changes in form fields as a whole, which can help to avoid unnecessary data access, reduce coding, and enrich the user experience. I hope you enjoy the technique and use it in your applications. If you want to use it in ASP.NET 2.0, simply recompile the code in Visual Studio 2005.

Bill Xie is a .NET solution architect, hands-on developer, and software consultant based in southern California. He has extensive experience developing Web applications, Windows applications, and distributing applications in different types of industries including insurance, financial services, and IT management. He has had articles published in CoDe Magazine, on DevX, asp.netPRO, ASPToday, and The Code Project.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date