Programming Microsoft ASP.NET 4 - Dino Esposito [450]
protected void Page_Init(object sender, EventArgs e)
{
// Work around the limitations in the API of the ScriptManagerProxy control
ScriptManager.GetCurrent(this).EnableScriptLocalization = true;
}
In the content page, you create a handler for the page’s Init event, retrieve the script manager instance using the static GetCurrent method on the ScriptManager class, and apply any required change.
Considerations Regarding Partial Rendering
Partial rendering divides the page into independent regions, each of which controls its own postbacks and refreshes without causing, or requiring, a full-page update. This behavior is highly desirable when only a portion—and perhaps only a small portion—of the page needs to change during a postback. An ASP.NET page can contain any number of UpdatePanel controls. This is a key point to understand to make effective use of the UpdatePanel control.
The first practical step for successfully migrating page behavior to partial rendering entails that you, given the expected behavior of the page, identify the portions of the page subject to refresh. If you have, say, a complex table layout but only a small fragment of only one cell changes in the page lifetime, there’s no reason to keep the whole table in an UpdatePanel control. Only the server-side control that displays the modifiable text should be wrapped by the panel.
The portions of the page that you should consider to be candidates to be wrapped by an UpdatePanel control should be as small as possible. They also should include the minimum amount of markup and ASP.NET controls.
The second step consists of associating each candidate region with a list of refresh conditions. You basically answer the question, “When does this region get updated?” After you have compiled a list of candidate regions, and for each you have a list of refresh events, you’re pretty much done.
The final step is mapping this information to UpdatePanel controls and triggers. If all the regions you have identified are disjointed, you’re fine. If not, you use properties and triggers on the UpdatePanel control to obtain the expected page behavior, thereby minimizing the impact of postbacks and page flickering.
If needed, updatable panels can be nested. There’s no syntax limitation to the levels of nesting allowed. Just consider that any nested panel refreshes when its parent is refreshed, regardless of the settings.
Let’s be honest. It might not be a trivial task, and getting a disjoint set of regions is not always possible. However, given the number of properties supported by the UpdatePanel control, there’s always room for a good compromise between user experience and performance.
Configuring for Conditional Refresh
An UpdatePanel control refreshes its content under the following conditions:
When another UpdatePanel control in the same page refreshes
When any of the child controls originates a postback (for example, a button click or a change of selection in a drop-down list with AutoPostBack=true)
When handling a postback event the page invokes the Update method on the UpdatePanel control
When the UpdatePanel control is nested inside another UpdatePanel control and the parent update panel is updated
When any of the trigger events for the UpdatePanel occur
You can control these conditions through a number of properties such as UpdateMode and ChildrenAsTriggers, as well as the collection Triggers. To minimize the total number of post-backs and the amount of data being roundtripped, you should pay a lot of attention to the values you assign to these properties. Let’s delve deeper into this topic.
Detecting Postbacks from Child Controls
By default, all updatable panels in a page are synchronized and refresh at the same time. To make each panel refresh independently from the