Learn the ASP.NET Page Life Cycle So you want to fully understand what is going behind the scenes when a ASP.NET page loads do you? In general, the life cycle of a ASP.NET page comprises of a series of steps like initialization, instantiation of controls, state management, the firing of event handler code, and the final stage of rendering. Why learn the various stages of an ASP.NET page? Well if you are a control developer, you have to know the various stages of a page so you can code for the appropriate stage of a page. For example, if you want to perform validation checks on your custom control, you won’t get the desired results if you try and perform validation during the rendering stage! If you are coming from a ASP.NET 1.1 background, be sure to note that ASP.NET 2.0’s page life cycle has been modified by giving you a finer control of the various stages. The following are the various stages a page goes through: Page Request The request page is either parsed or compiled, or fetched from the cache. Start Page properties like the Request and Response are set. The type of request is determined, specifically whether it is a new Request or it is a PostBack. Culturing properties are also determined via the pages ICulture property. Page Initialization All the controls on the given page are initialized with a UniqueID (please don’t confused this with the ID property as the UnqiueID is a unique, hierarchicial identifier which includes the server control’s naming container). Theming is also applied at this stage. Load If the current request is a PostBack, the data from the viewstate and control state is loaded to the appropriate properties of the controls. Validation The Validate method of all the validator controls are fired, which in turn sets the Boolean property IsValid of the controls. Postback Event Handling If the current request is a PostBack, all event handlers are called. Rendering ViewState data is saved for all the controls that have enabled viewstate. The Render method for all the controls is fired which writes its output to the OutputStream via a text writer.

Unload Once the page has been rendered and sent, the Page’s properties are unloaded (cleanup time). So know you have a better understanding of the various stages of a ASP.NET pages life cycle, you should be aware that within each of the above stages there are events that you can hook into so that your code is fired at the exact time that you want it to. Event Wire-up is another important concept to understand. So Event wire-up is where ASP.NET looks for methods that match a naming convention (e.g. Page_Load, Page_Init, etc) , and these methods are automatically fired at the appropriate event. There is a page level attribute AutoEventWireup that can be set to either true or false to enable this behaviour. Below are some of the more popular events that you should understand as you will most likely be interested in them: PreInit You can use this event to: Create /recreate dynamic controls Set a master page or theme dynamically Access profile properties Init Used to read or initialize your control properties. InitComplete Used when you need to access your properties after they have been initialized. PreLoad Used when you need to process things before the Load event has been fired. Load The Page’s OnLoad method and all of its child control’s OnLoad method are fired recursively. This event is used to set properties and make database connections Control Events Control specific events are handled at this stage. e.g. Click event’s for the button control. LoadComplete This stage is for when you need to access controls that have been properly loaded. PreRender Can be used to make any ‘last chance’ changes to the controls before they are rendered.

SaveStateComplete This event is used for things that require view state to be saved, yet not making any changes to the controls themselves. Render The page object calls this method on all of the controls, so all the controls are written and sent to the browser. Unload All the controls UnLoad method are fired, followed by the pages UnLoad event (bottom-up). This stage is used for closing database connections, closing open files, etc. It is import to understand that each server control has its very own life cycle, but they are fired recursively so things may not occur at the time you think they do (they occur in reverse order!). What this means is that some events fire from the bottom up like the Init event, while others load from the top-down like the Load event. Summary So we learned about the various stages of an ASP.NET page, and I also covered some popular events that you might want to override or program for in your applications. If you don’t understand what is happening at the correct stage, you will either throw an exception since you are trying to access something that is not available at this stage, or you will go through long bouts of debugging trying to figure out why are program is not behaving the way you expect it to. Master Pages in ASP.NET 2.0 So you have heard of Master pages but haven’t really gotten around to research what is all about? If this is you, read on! Master Pages enables you the developer to create a consistent look and feel for your web application. For most of us, we either create a header and footer on each and every webpage or we create a header and footer control and then add those controls to each and every .aspx page. Ofcourse some might have seen the pitfall in this method and weaved their own custom page that dynamically adds both the header and footer to their pages automagically. Well the good news is this is now built in, and here is a quick and simply overview of how MasterPages works in ASP.NET 2.0. Master Pages 101 A master page is similar to a ‘.aspx’ page except that it has its own unique extension, ‘.master’. Furthermore, a master page contains a new ‘Master’ directive, along with a ContentPlaceHolder control. The ‘master’ directive tells us that this page is a master page, and the ContentPlaceHolder control is a placeholder (as the name suggests) for a content area where your content pages will ‘inject’ their content into the template. Keep in mind your master page can contain multiple ContentPlaceHolder tags, your content pages will simply reference the ID of the ContentPlaceHolder to ensure the content is injected into the correct area of the template.

So putting this knowledge to work, let’s create a very simply Master Page: <%@ Master Language=”C#” %> <script language=c# runat=server> // your code here you wish!

Look Mom, default content that will render only if not overridden on the content page!

So you will notice the master page has that master directive I mentioned earlier, along with the ContentPlaceHolder. You will notice that within the ContentPlaceHolder control there is some content. This content will render in any content page that doesn’t reference this ContentPlaceHolder’s ID, so in effect you can have default content on all your content pages which is overridden if you have content. Once you have your master page, you obviously want to create content pages using your master page as a template. Your content page will be like any other .aspx page you have created in the past, except that it will reference the master page in the Page Directive and it will contain a Content Control and between this control will be all your content or at least the all the content for the corresponding ContentPlaceHolder contron in your master page. <%@ Page Language=”C#” MasterPageFile=”~/csharpfriends.master” %>

Look Mom, actual content on my content page! Looks like I’m going to make it after all!

As I mentioned earlier, your master page can contain numerous content areas using ContentPlaceHolder controls, just make sure to match up the ContentPlaceHolder’s ID in your pages. Basically want happens is that when your .aspx page renders, it will cycle through all the Content controls and match up the PlaceHolder in the master page. Master Page Configuration Options As it is now, it is possible to create content pages that don’t use the master page by simply NOT referencing the master page. This could be something you want, or it could be something you don’t want. To force pages to use the master page layout you can modify you web.config file by adding this XML tag. Keep in mind that even though a master page is forced on all pages, if the .aspx page references another master page file it will override your web.config settings. <system.web> <pages masterPageFile=”csharpfriends.master” />

This tutorial on master pages is for beginners, hings can get more complicated with master pages, such as programmatically including master pages in your content pages, nesting master pages and how events work etc. These topics might come in future articles so keep a eye out for them. Summary In this brief article, I outlined the benefits of using Master Pages, the differences between a master page and a regular aspx file along with a simple implementation and possible configuration options you have. ASP.NET 2.0 – What’s New? So you want to know what all the ASP.NET 2.0 buzz is about right? Here is a quick glance of new things to learn (and write about!) Developer Productivity ASP.NET 1.0 was great, but as with most technologies there can always be room for improvement. One of the design goals of 2.0 was to help make the lives of developers easier. The ASP.NET team surveyed the common tasks one does during development, and encapsulated them into controls and services (which also helps reduce the number of lines of code!). These new controls encapsulate common tasks like user personalization, data access, memberships and roles and even navigation (think treeview, menus and yahoo like breadcrumbs). One thing that was custom coded in most web applications was common headers and footers on websites. ASP.NET 2.0 now comes with ‘master pages’ which gives you the ability to define common elements of your web page like headers, footers etc. Localization was also improved, allowing you to know auto-detect the visitors locale and display data accordingly. Dynamic generation of resource files is now a built-in tool with Visual Studios 2005. Configuration Management and General Administration Several new enhancements can be found in 2.0 that enable easier deployment, management and general operation of ASP.NET enabled servers. Configuration management APIs now give you the ability to read, update and even create web.config files. You can finally precompile your application before deploying it. Previously you had to either hit each and every page so ASP.NET compiles your site, or you used some sort of a tool that basically ‘walked’ your site to ensure the pages have been compiled. Performance 64-Bit support means ASP.NET can take advantage of the full memory address space on 64-bit cpu’s. Caching has also been improved upon, now allowing the developer to set custom dependencies, post-cache substitution which improve your ability to custom your caching. Managing the cache is now even easier, with the ability to create ‘cache profiles’ and tweak a ‘cache configuration’. Basically what happens is that you create a cache profile which you can then use on your pages which allows you to manage caching on many pages by simply modifying your cache profile.

For increased scalability, you can now set ‘SQL cache invalidation’ and ‘disk output cache’. SQL Cache Invalidation will cache the data until the data actually changes at the database level (as oppose to time based). Disk output cache will cache the data to disk (not only memory), thus allowing for more pages to be cached since you are not limited to your servers memory limit. I know that was a quick summary, but look for more detailed explanations of each in future articles.