Watch videos with subtitles in your language, upload your videos, create your own subtitles! Click here to learn more on "how to Dotsub"

Page Lifecycle Events

0 (0 Likes / 0 Dislikes)
  • Embed Video

  • Embed normal player Copy to Clipboard
  • Embed a smaller player Copy to Clipboard
  • Advanced Embedding Options
  • Embed Video With Transcription

  • Embed with transcription beside video Copy to Clipboard
  • Embed with transcription below video Copy to Clipboard
  • Embed transcript

  • Embed transcript in:
    Copy to Clipboard
  • Invite a user to Dotsub
[] [Joe] Hi folks, Joe from Microsoft here with video number 5 in this video series on building web applications using Microsoft Visual Web Developer. We're well on our way to the foundational understanding that's necessary to start building applications. But there's one more set of things I think we should review before we build our first page and start using the controls that are avilable with And that is the events in the page lifecycle. Now there is an entire lifecycle for a page request that happens when a user requests an page from their browser. When IAS receives that request and hands it off to the handler, there's some things that happen right away. The request object is created. A response object is also created to be populated throughout the page lifecycle. Also the is post-back variable is set so that in our code we can determine whether or not this is the first time that the page is being rendered or whether or not it's a subsequent request, so the page has been rendered once and it's been posted back so that we can make some updates to the mark-up that's on the page. And then inside the lifecycle of the page, there are a collection of events that we as developers can program against. And I thought it would be interesting for us to iterate through those events and see what they do and how we can use them in our application code. So to begin with, I have an empty website here and we're going to start by flipping through the events in the sequence that they get fired and seeing what we might use those events for. So let's get started. So let's generate an unload event handler. Remember, the page has already been rendered at this point. So you can't make any changes to the content of the page. In fact, if you try and do something like call response.right, you'll actually get an exception, because the page is complete. So this is sort of after processing. And there's an unload event that gets fired both for the page as well as for every control on the page. It's where you do final clean ups. Things like maybe you need to make sure that you close any files that you've opened from the file system, or release any database connections or what-have-you. But this is sort of wrap-up. Remember, you can't make any changes to the content on the page, doing so will likely generate an exception for you. But you can do your clean-up here. Then once you've done that, that's the basics in the events of the page lifecycle that we might want to program against when we're building our applications. So here we are in the code behind file for default.aspx page. And you'll recall that this is server-side logic. So this gets executed when a page is requested for the first time or if the page has already been rendered, we get what's called a post back and the server is called on to re-render this same page with whatever changes are appropriate based on the changes that have been made by the user as they're working with the web page in the browser. So in the lifecycle there is a series of common events and we're going to evaluate a bunch of them. Let's add them one at a time. So the first event that gets fired is the pre-init event. Now there may be other events that get fired here under the covers, but we're just going to look at the most commonly accessed ones by developers. So to begin with, we're interested in the pre event. So let's chose page events from the events collection. Let's look at the drop down. You'll notice that these are in alphabetical order, not chronological order. So we're going to choose first, pre-init. There's one particularly interesting thing we want to remember here, is that if this post is a post back, if this request for this page is a post back, then we can check the is post back property. Because it's already been set. So if we need to make the determination very early on in the lifecycle whether or not this is an initial rendering of the page or a post back, we can do that by checking the is post back property. But having said that, if this is a post back the values for any of the controls that exist on the page, haven't been reconstituted from view state yet. So this is very early on in the lifecycle. The kinds of things that you would use, the page pre-init event handler for are to set things that are global to the page, like if you're going to dynamically set a master page or a theme property, for example. Maybe you're making a decision based on the geography or the time of day or the day of the year or what have you, you could dynamically set a master page or a theme property here in the page pre-init event handler. You could also set profile properties if you're using the profile system. The other thing you might do here is to create or re-create dynamically created controls. So if you have controls that appear on your page, but aren't established at design time but they're dynamically added by logic—program logic in your code behind, then the pre-init event handler might be a place to reconstitute those controls as well. Next, we have the pages init event. So let's go ahead and generate an init event handler. Init gets fired after all of the controls on the page have been initialized and any skin settings have been applied to those controls. So it's in the init event handler where we might want to re-write any specific control properties. Then we have the init complete event handler. So let's go ahead and implement the init complete event handler. Now init complete fires after all of the initialization has taken place. So if you have to implement logic that depends on things like the page or controls to be initialized, the init complete method is the place for that logic to be implemented. Now we're getting ready to start loading the page. And the next event in the series is the preload event. So let's go into the drop down, choose preload. Preload is where you would perform any processing on your page or on a control before it's load event. So the page preload event fires, then the preload events for all of the controls on the page fire. Then it's after this, that view state gets initialized, and all of the post back data gets initialized from the request object. Now we've finished the preload event handler, view state has been reconstituted, and any post back data has been processed from the request instance. Now we're ready for the all powerful load event handler. So let's go ahead and generate that. Now in addition to the page load event handler being called, the page load event gets fired and then recursively all of the unload event handlers for all of the child controls on the page are fired as each one is loaded. So we get the page load event handler and then the unload event handler for each of the controls that are contained on the page. Once all of those load event handlers have fired, the next thing that happens is any specific control event gets fired for any configured event handler. For example, if you're using a text box and you've implemented a text changed event handler, it would get fired at this point in time. Now if you're not familiar with control-specific events, don't worry about that, because in an upcoming video I'm going to show you how to use some of the specific controls and configure some of the control-specific events and event handlers. So suffice to say that after the page load event and the control load events are fired, then all of the specific control events are fired, then we're ready for the load complete event handler. So let's generate load complete. Remember, at this point the controls are all loaded, their view state has all been reconstituted. If there's any validation properties, or if there are any validation controls that have been implemented on your page or for controls on your page, the validation is executed now. In load complete, we can implement any tasks that require all of the other controls on the page to be loaded and validated. So that's the kind of stuff we would enter in load complete. At this stage the controls have been created in memory, and we need to get ready to actually render those controls, so that the mark-up can be sent back down to the browser. So the next event that we're interested in handling is the pre-render event. So we'll generate a pre-render event handler. A couple of things to remember, before the pre-render event gets fired, the page object calls ensure child controls for every control on the page, every data-bound control that has a datasource ID property set has it's databind method called, and this occurs for each control on the page. So there's a pre-render control for each control on the page. Then the page pre-render event itself gets fired. So you would use the page pre-render event to make any final changes to the content of this page or the controls on this page before it's actually turned into html for sending down to the browser. You're probably thinking after pre-render it's time for the page to be rendered. But there's one more event of interest to us. And that is the save state complete event. So lete's go ahead and generate a save state complete event handler here. Before the save state complete event gets fired, view state for the entire page and for all of the controls on the page has been saved. So any changes that are made to the state of the page or the controls on the page from this point forward won't be rendered and sent down to the browser. They'll just be ignored. In this event handler, we might implement any logic that requires view state to be completed. So the values of all the controls that are going to be sent down to the browser, have been created and saved here and we can execute logic against those. We just can't implement any logic that wants to change what's going to appear on the page, because at this point all of those changes can appear. Now the page can be rendered. Now there's no actual render event. Instead, at this stage in the processing the page object calls the render method on every single control that exists on our page. That's when the rendering actually takes place, whether it's for built-in controls, custom controls, user controls, or what have you. Then all of the output is emitted for sending down to the browser and there's one last event that we're interested in. []

Video Details

Duration: 12 minutes and 10 seconds
Country: United States
Language: English
License: All rights reserved
Genre: None
Views: 7
Posted by: neudesicasp on Sep 20, 2013

ASP.NET provides a very rich eventing mechanism with hooks into all the important chronological instances in the ASP.NET page lifecycle. This video will enumerate many of the common lifecycle events, their firing sequence and the kinds of things that you might use each event for.

Caption and Translate

    Sign In/Register for Dotsub to translate this video.