ASP.NET 2.0's Client Callback Feature

http://drdobbs.com/windows/219501054

Script Callbacks in ASP.NET 2.0

Let's face it: Web developers would give anything for a programmable tool that would allow them to avoid page refresh. Imagine the following, rather common, scenario: You add a grid control to an ASP.NET page and make it show users a navigation bar. Whenever the user clicks to display a new set of rows, the page posts back, performs some work on the server, and then reappears identical to the previous time (except for the new set of grid rows). This process carries a significant performance hit, especially for large and complex pages. Why on earth, developers wonder, should 50 Kb of stuff have to be downloaded for each user action (and a good part of it also uploaded with the same frequency)?

Being able to update client data without causing the entire page to post back is an old dream for Web developers. Ideally, they should be able to wire up client code to call the server, execute an event, take the returned data, and update only the portion of the client page touched by the action.

ASP.NET 1.x and classic ASP enabled this function, but the developer had to accept an ActiveX control or at least a Java applet on the page to act as an intermediary. The intermediary received calls from the client's script code and set up a parallel, invisible connection to a server page. The server page got some input and returned some output. The output returned through the invisible connection was processed on the client and used to update the page via the Dynamic HTML (DHTML) object model.

ASP.NET 2.0 abstracts the developer from the creation of the request to the server and the logic needed to parse the server's response. Script callbacks in ASP.NET 2.0 offer a ready-to-use mechanism that greatly simplifies the procedure. More importantly, they hide a lot of the implementation details and shield you from a bunch of browser issues.

Script Callback Requirements

In the Microsoft world, the first implementation of callbacks was Remote Scripting (RS). RS leverages a Java applet to connect to the server and requires an ASP page to serve the request. In addition, the ASP page provides a made-to-measure object model—a sort of public and common interface—for the interaction to take place. In ASP.NET, the overall model is similar but the tools employed are different.At the core, ASP.NET script callbacks consist of some client-side JavaScript code that arranges for a programmatic roundtrip to the server. So, the first requirement for using the callbacks is that some server-side code awaits client calls. The client-side callback intermediary manages the call while the user continues to see the old page and interact with it. The callback mechanism leaves the current page unaffected and gives users the illusion that everything is taking place on the client like in a classic desktop application. Hence, the second requirement is that the browser provides DHTML capabilities and offers an advanced DOM implementation. Without these capabilities, any downloaded information would mostly be useless.

How ASP.NET Script Callbacks Work

ASP.NET callbacks use the XmlHttpRequest DOM object to set up the connection. (As far as Internet Explorer is concerned, script callbacks require at least version 5.0.) The target of the remote invocation can be either a particular server control (for example, the new GridView control) or the page itself. In general, the target must be an object that implements the ICallbackEventHandler interface.

The following paragraphs show how to enhance a page to make it support script callbacks.

Related Articles

• ASP.NET 2.0 Options for Packaging and Deploying Web Apps
• ASP.NET 2.0 Moves User Authentication One Step Forward
• ASP.NET 2.0's New and Improved Caching Features
• ASP.NET 2.0's Sophisticated Site Navigation Features
• The ASP.NET 2.0 Provider Model

The first step is identifying the HTML element that triggers the operation. Typically, this element is a button or a link that users click. It is essential that the element fires an event that is not automatically handled by the browser and results in a postback. For example, you should never use an  element to trigger the callback because  generates a submit button. The following code is fine, if you want to start the operation with a button click:

This button—an instance of the HtmlInputButton control—needs some special JavaScript code to handle the click event. You can add the following code programmatically in the Page_Load event:

callbackStarter.Attributes["onclick"] = String.Format("javascript:{0}",
       callbackRef);

How do you determine the right script code to bind? The GetCallbackEventReference function on thePage class can help. Here's an example:

string callbackRef = GetCallbackEventReference(
    this,
    "document.all['cboEmployees'].value",
    "UpdateEmployeeViewHandler", "null", "null");

The GetCallbackEventReference function's first argument indicates the target object that will handle the call on the server. If you pass this, you mean the page itself. You also can pass in a reference to any page control that implements the ICallbackEventHandler interface. In any case, the client-side submit action will hit the same ASPX page through the standard postback mechanism.

The second argument is a constant or a JavaScript expression that represents the input sent to the server. In the code above, you pass the value of the currently selected element of a drop-down list. (See the full source code.)

The third argument is the name of a user-defined JavaScript callback function defined in the

Optimal Normal Form

6. Optimal Normal Form
At this point, we have done all we can with Entity-Relationship Diagrams (ERD). Most people will stop here because this is usually pretty good. However, another modeling style called Object Role Modeling (ORM) can display relationships that cannot be expressed in ERD. Therefore there are more normal forms beyond 5th. With Optimal Normal Form (OMF)
It is defined as a model limited to only simple (elemental) facts, as expressed in ORM.

---

7. Domain-Key Normal Form
This level of normalization is simply a model taken to the point where there are no opportunities for modification anomalies.

"if every constraint on the relation is a logical consequence of the definition of keys and domains"

Constraint "a rule governing static values of attributes"

Key "unique identifier of a tuple"

Domain "description of an attribute’s allowed values"

1. A relation in DK/NF has no modification anomalies, and conversely.
2. DK/NF is the ultimate normal form; there is no higher normal form related to modification anomalies
3. Defn: A relation is in DK/NF if every constraint on the relation is a logical consequence of the definition of keys and domains.
4. Constraint is any rule governing static values of attributes that is precise enough to be ascertained whether or not it is true
5. E.g. edit rules, intra-relation and inter-relation constraints, functional and multi-valued dependencies.
6. Not including constraints on changes in data values or time-dependent constraints.
7. Key - the unique identifier of a tuple.
8. Domain: physical and a logical description of an attributes allowed values.
9. Physical description is the format of an attribute.
10. Logical description is a further restriction of the values the domain is allowed
11. Logical consequence: find a constraint on keys and/or domains which, if it is enforced, means that the desired constraint is also enforced.
12. Bottom line on DK/NF: If every table has a single theme, then all functional dependencies will be logical consequences of keys. All data value constraints can them be expressed as domain constraints.
13. Practical consequence: Since keys are enforced by the DBMS and domains are enforced by edit checks on data input, all modification anomalies can be avoided by just these two simple measures.