Traditional Web applications mitigate server loading and enhance the user experience by embedding logic in client scripted algorithms. Form validation, data sorting, and paging functionality are often performed on the client, as are user message boxes, dynamic text elements, and pop-up menus. Such client-side scripting makes for a vibrant user experience while requiring little server interaction. By distributing the computational needs of specific functionality to their clients, traditional Web systems have achieved a bit of a free ride—dynamic functionality without additional server loading. Most highly trafficked, public Web sites couldn’t scale to their user base (or achieve the desired interactivity) without considerable use of client-side scripting.
Microsoft’s .NET facilitates a broader set of functionality for Web applications. It establishes a bias for server-side programming that may be uncomfortable for those used to extensive client-side scripting. While adapting to the new paradigm, developers will have to learn how to judicially apply postbacks for optimum event handling on the server without sacrificing application response or scalability. Additional challenges surface when assigning event-driven, browser-based functionality to rendered server controls.
Limiting browser exposure through .NET
.NET’s focus on server programming will immediately become apparent to the developer considering server postbacks. Postbacks are associated with any Web control event and are basically requests for processing sent to the server. For example, assuming an event handler has been written, a list box will fire an event anytime a user selects a new item. Posting back to the server allows that event to be handled by initiating a round trip to the server. While server requests are certainly not new to .NET, you do need to consider their frequency. .NET applications, if coded unwisely, can post back to the sever with nearly every event on every control. Obviously the network traffic and server loading will result in extreme latencies under even moderate traffic.
.NET mitigates postback overuse by allowing developers to disable automatic postbacks on some controls. Rather than automatically initiating a postback when the user changes the control, events are cached and submitted on the next post when autopostback is disabled. Some controls however, such as the Calendar and DataGrid control, don’t allow the disabling of the autopostback functionality. These controls will initiate a server round trip with every change to the control.
Additionally, the control’s view state can be set to help minimize network traffic. The view state enables server controls to maintain their contents over a browser refresh. Since this is done via passing the control’s serialized values back and forth between the browser and the server, disabling the view state when not necessary will improve performance.
Back to the client
Certain basic application functionality is currently impossible to handle strictly from the server. For example, consider setting the focus on a TextBox server control. Currently, there is no .NET method or property available to set focus to any server control, and the request must be handled through client script. With a control placed directly on a Web form, this is a relatively straightforward scripted operation: Access the server control by its ID and invoke the focus method.
The situation becomes more complex, however, when the target control is the child of a DataGrid, DataList, or other compound control. Let say, for example, that you want to set the focus to a TextBox inside a DataGrid control when the grid is first put into edit mode. As with a stand-alone control, you’ll use the ID of the control when you invoke the focus method call. However, at design time, the specific TextBox doesn’t yet exist since the grid isn’t yet populated. So you have to create the client script at run time on the server (i.e., on the edit event) and then render it to the client. Since the client script must specify the ID of the target control, your application code will have to determine the selected row and column in the DataGrid and then locate the associated TextBox control’s ID.
Similar difficulties arise for triggering the simplest of client interactions, the alert box. Because an alert box is solely browser-based functionality, .NET does not have an activation mechanism. In this case, a client script must be rendered that accesses the browser DOM and invokes the alert method. The client script itself is trivial; however, when combined with, say, the delete action from a DataGrid server control, you’re again in the situation where you must write server code to discover the child control’s ID and embed it in rendered client script.
Never say never