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.
Previous Page
