Jasinski Technical Wiki

Navigation

Home Page
Index
All Pages

Quick Search
»
Advanced Search »

Contributor Links

Create a new Page
Administration
File Management
Login/Logout
Your Profile

Other Wiki Sections

Software

PoweredBy

Chapter 03: Handling Events and Managing State - MCTS Exam 70-515

RSS
Modified on Wed, Dec 28, 2011, 8:56 AM by Administrator Paths: MCTS Exam 70-515 Categorized as MCTS Exam 70-515

Overview

Ways to persist state include the following.

  • View state
  • Hidden fields
  • Session state
  • Cookies
  • Query strings
  • Application state

Lesson 1: Understanding the ASP.NET Life Cycle and Handling Events

App Life Cycle

1. User requests a page

2. Route the request to processing pipeline, which forwards it to ASP.NET runtime

3. Create the ApplicationManager object — which holds the .NET domain for the application, isolating it from other apps.

4. Create the HostingEnvironment object — which provides access to directory folders, etc.

5. Create the HttpContext, HttpRequest, and HttpResponse objects.

6. Create/reuse the HttpApplication object — which is the base class for the Global.asax file, and hosts events for the application startup and stop.

7. Requests are processed through the HttpApplication pipeline — which includes a set of events for validating requests, mapping URLs, accessing the cache, etc.

Application-Level Events

  • Application_Start

  • Application_End

  • Application_Error — fires when an UNHANDLED exception occurs.

  • Application_LogRequest — fires when a request is made to the app.

  • Application_PostLogRequest — fires after the logging of the request is completed.

Page Life Cycle Events

EventUsage
PreInit
  • Set Master Page
  • Set page theme
  • Create dynamically created controls on a page not having a master page
InitFires after each control has been initialized
  • Change initialization values for controls
  • Dynamically add controls to a content page.
InitCompleteFires after all initializations (of page/controls) are completed.
PreLoadFires before view state has been loaded, and before postback processing
LoadPage is stable, having been initialized and its state been reconstructed. The page's load event is called first, then that for its child controls, then their child controls, etc.
Control (postback) eventsFor example: button Click event
LoadCompleteFires after all controls are loaded.
PreRenderFires after all regular postback events fire, but before ViewState is saved. Allows final changes to the page or its controls.
  • Make changes to ViewState
SaveStateCompleteFires after ViewState (for page/controls) is set, so any change at or beyond this point is ignored.
Render methodASP.NET calls this method for each control to generate the HTML, DHTML, and scripts.
Unload
  • Cleanup code (rarely used)

Lesson 2: Using Client-Side State Management

Ways to persist state on the client include the following.

  • View state
  • Hidden fields
  • Session state
  • Cookies
  • Query strings

Lesson 3: Using Server-Side State Management

Ways to persist state on the server include the following

  • Session state
  • Application state

Choosing Session State Mode

Session State Mode is set in the web.config file in the /configuration/system.web/sessionState node and can be read via the System.Web.SessionState.HttpSessionState.Mode property in code. Modes other than InProc and Off require additional configuration parameters, such as connection string.

  • InProc — stored in memory on the web server; this is the default.
  • StateServer — stored in the ASP.NET State Service; available to multiple servers; preserves state if the web app is restarted.
  • SQLServer — stored in a SQL Server database.
  • Custom — stored in whatever custom session state storage provide that you manually code.
  • Off — disables session state to improve performance.

ScrewTurn Wiki version 3.0.1.400. Some of the icons created by FamFamFam. Except where noted, all contents Copyright © 1999-2024, Patrick Jasinski.