Programming Microsoft ASP.NET 4 - Dino Esposito [457]
These days, the winning library for client-side programming is jQuery. (I’ll cover the library in the next chapter.) An important extension to the library is jQuery UI, which solves at the root most of the issues I mentioned earlier regarding update progress and client-side widgets.
You should be aware of the structural limitations that partial rendering has. Let’s review the most important. If any of them are likely to affect you, you better look elsewhere and re-architect your application.
Issues with Concurrent Calls
Partial rendering doesn’t support concurrent asynchronous postbacks. This means that you are not allowed to have two asynchronous postbacks going on at the same time. Partial rendering ultimately works by bypassing the standard browser mechanism that handles an HTTP request. It hooks up the submit event of the form, cuts out the standard browser handler, and places the HTTP request using XMLHttpRequest.
The request that reaches the Web server differs from a regular ASP.NET request only because it has an extra HTTP header. The request sends in the contents of the posting form, including the view-state hidden field. The response is not pure HTML but represents a text record where each field describes the new status of a page element—update panels, hidden fields, and scripts to run on loading.
As you can see, the underlying model of partial rendering is still the model of classic ASP.NET pages. It is a sort of stop-and-go model where the user posts back, waits for a while, and then receives a new page. While waiting for the next page, there’s not much the user can do. Only one server operation per session occurs at a time. Partial rendering is only a smarter way of implementing the old model.
From a technical standpoint, the major factor that prevents multiple asynchronous postbacks is the persistence of the view-state information. When two requests go, both send out the same copy of the view state, but each reasonably returns a different view state. Which one is good for the page, then? Partial rendering takes a defensive approach, and it silently kills the ongoing request whenever a new request is placed—a last-win discipline.
By writing some JavaScript code around the BeginRequest client event, you can turn the discipline into a first-win approach, at the cost of losing the new request. It is your responsibility to queue the stopped request and run it later. This is just what some commercial Ajax frameworks do.
This fact has a clear impact on developers. In fact, you should always modify the user interface to ensure that users can’t start a second operation before the first is terminated. Otherwise, the first operation is aborted in favor of the second. This happens in any case, even when the two operations are logically unrelated.
Note
When concurrent calls are necessary, you should consider moving that page (if not the whole application) to a more AJAX-oriented design. Alternatively, you can consider implementing that feature within the page using direct script-led calls to URL-based endpoints. I’ll cover this approach in a moment.
Issues with Polling
Among other things, Ajax pages are popular because they can retrieve the client information in a timely manner. A page starts polling a remote URL, grabs fresh information, and returns it to the client for the actual display. Implemented via partial rendering, polling is subject to being interrupted when the user starts a new partial rendering operation to restart automatically at the end.
If this is not a problem for you, you can use the new Timer server control, as shown here:
