MSDN Magazine - August 2008 - (Page 36)

dynamic and interactive content doesn’t reduce your chance of developing multiple blocks of content at the same time—an ASCX control is a sort of ASP.NET page and can be developed independently from the rest of the site. Dynamically Loaded Controls In ASP.NET, dynamically loaded controls require a bit of attention because of their behavior across postbacks. Suppose you create a user control that contains a pageable grid of customers, excellent storage medium for this type of information. In Figure 3, I added the TrackUserControl property to the page class to remember which user control is currently displayed. In the Page_Load event, you use the content of the TrackUserControl property to figure out which user control has to be manually reloaded in order to restore exactly the same collection of controls the page contained last time: void Page_Load(object sender, EventArgs e) { if (!IsPostingFromMenu() && IsPostBack) ReloadContent(); } ASP.NET page output caching allows you to cache page and user control responses. and then you load the user control into the placeholder (see Figure 4). Everything works just fine until you click one of the bottom hyperlinks to navigate to a new page. When this happens, the page partially refreshes, but the whole content of the user control disappears. Why? In ASP.NET, each page request is treated independently from any other previous or successive requests. So a brand new instance of the page class is created to service each incoming request. This new page contains fresh instances of all server controls that are statically referenced in the ASPX source code. But what about the dynamically added controls? The page doesn’t know about them unless the code in the page uses some persistence mechanism to track dynamic controls. The page view state is an Figure 3 Dynamically Loading Content into the Page public partial class _Default : System.Web.UI.Page { public string TrackedUserControl { get { return ViewState["TrackedUserControl"] as string; } set { ViewState["TrackedUserControl"] = value; } } protected void Menu1_MenuItemClick(object sender, MenuEventArgs e) { LoadContent(e.Item.Value); } private void LoadContent(string menuItemName) { string ucUrl = menuItemName + ".ascx"; UserControl uc = null; try { uc = this.LoadControl(ucUrl) as UserControl; } catch(Exception ex) { } if (uc != null) { Placeholder1.Controls.Add(uc); TrackedUserControl = ucUrl; } Note, though, that the postback may have one of two causes—either the user triggered an action from within the displayed user control or the user clicked another menu item. The if statement in Page_Load determines whether the user is posting from the menu. If so, nothing happens because some new content has to be loaded; otherwise, the tracked user control is reloaded so that it can handle the postback event: void ReloadContent() { UserControl uc = null; try { uc = this.LoadControl(TrackedUserControl) as UserControl; } catch { } if (uc != null) Placeholder1.Controls.Add(uc); } } } What about the view state for the dynamically added user control? And what about any data that HTML elements may have posted to it? When the user is served a page, there is no distinction between statically and dynamically added controls. Any input the user enters (for example, text in an input field) is automatically packed into the HTTP request when the form is submitted. On the server, therefore, any information to be consumed by the dynamically loaded control is available. However, you should know that when the page’s Init event fires, no such control is yet available. This is because the page’s control tree is only populated with statically referenced controls. It is up to the page author to add any dynamically referenced controls to the tree. The page author, though, may need to read about added controls from a persistent storage medium. If this information is stored in Session or Cache, then you can safely access it from the Init event handler. If that information is stored in the view state bag, then you have to wait for the Load event. In the ASP.NET page lifecycle, in fact, the view state is unpacked and processed between the Init and Load events. At this stage, any posted data is also examined and mapped to existing controls. But what about the data that is destined for dynamically added controls? Basically, posted data is processed in one of two passes—once before or once after the Page__Load event. Data for which no matching control is found in the first round is cached and processed again after the Load event. In the Load event, developers should check which controls were dynamically added the previous time and reload them in the page Cutting Edge 36 msdn magazine

Table of Contents Feed for the Digital Edition of MSDN Magazine - August 2008

MSDN Magazine - August 2008 Toolbox CLR Inside Out Basic Instincts Cutting Edge Patterns in Practice Data 2.0 - Expose And Consume Data In A Web Services World Biztalk EDI - Build A Robust EDI Solution With BizTalk Server Silverlight - Create Animations With XAML And Expression Blend Write On! - Create Web Apps You Can Draw On With Silverlight 2 Wicked Code - Craft Custom Controls For Silverlight 2 Team System Foundations Windows With C++ Concurrent Affairs Going Places { End Bracket }

MSDN Magazine - August 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.