母版页与内容页的调用顺序.doc

母版页与内容页的调用顺序母版页与内容页的调用顺序2011-03-13 10：22母版页和内容页都可以包含控件的事件处理程序。对于控件而言，事件是在本地处理的，即内容页中的控件在内容页中引发事件，母版页中的控件在母版页中引发事件。控件事件不会从内容页发送到母版页。同样，也不能在内容页中处理来自母版页控件的事件。在某些情况下，内容页和母版页中会引发相同的事件。例如，两者都引发Init和Load事件。引发事件的一般规则是初始化事件从最里面的控件向最外面的控件引发，所有其他事件则从最外面的控件向最里面的控件引发。请记住，母版页会合并到内容页中并被视为内容页中的一个控件，这一点十分有用。下面是母版页与内容页合并后事件的发生顺序：母版页控件Init事件。内容控件Init事件。母版页Init事件。内容页Init事件。内容页Load事件。母版页Load事件。内容控件Load事件。内容页PreRender事件。母版页PreRender事件。母版页控件PreRender事件。内容控件PreRender事件。关于中页面事件加载的先后顺序Page执行中将按照如下顺序激活事件：Page.PreInit Page.Init Page.InitComplite Page.PreLoad Page.Load Page.LoadComplete Page.PreRender Page.PreRenderComplete如果页面从另一个页面继承，如basePage：System.Web.UI.Page，在basePage中做了一些扩展，如权限检查，而其他页面从basePage继承，则basePage和最终Page的事件激活顺序是：UI.PreInit Page.PreInit UI.Init Page.Init UI.InitComplite Page.InitComplite UI.PreLoad Page.PreLoad UI.Load Page.Load UI.LoadComplete Page.LoadComplete UI.PreRender Page.PreRender UI.PreRenderComplete Page.PreRenderComplete如果使用了MasterPage，则MasterPage中的事件和ContentPage中的事件按照下面顺序激活：ContentPage.PreInit Master.Init ContentPage.Init ContentPage.InitComplite ContentPage.PreLoad ContentPage.Load Master.Load ContentPage.LoadComplete ContentPage.PreRender Master.PreRender ContentPage.PreRenderComplete更进一步，如果ContentPage继承basePage，那么，各事件的执行顺序将变成：UI.PreInit ContentPage.PreInit Master.Init UI.Init ContentPage.Init UI.InitComplite ContentPage.InitComplite UI.PreLoad ContentPage.PreLoad UI.Load ContentPage.Load Master.Load UI.LoadComplete ContentPage.LoadComplete UI.PreRender ContentPage.PreRender Master.PreRender UI.PreRenderComplete ContentPage.PreRenderComplete浏览下来发现并不是我现在所学的1.1，估计应该是2.0不过也没有关系，这让我知道了他们有继承时加载的顺序。即：先加载继承页的，再加载自己的，如果继承页有继承则先加载继承页的继承。其实是个很简单的内容。顺便写下Page事件(不知道1.1是不是就这些)事件处理器名称发生时间Page_Init在Web窗体的视图状态加载服务器控件并对其初始化。这是web窗体生命周期的第一步Page_Load在Page对象上载入服务器控件。由于此时视图状态信息是可以使用的，因此载这里可以用代码来改变空间的设置或者载页面上显示文本。Page_PreRender应用程序将要呈现Page对象Page_Unload页面从内存中卸载Page_Error发生未处理的异常Page_AbortTransaction事务处理被终止Page_CommitTransaction事务处理被接受Page_DataBinding把页面上的服务器空间和数据源绑定载一起Page_Disposed Page对象从内存中释放掉。这是Page对象生命周期中的最后一个事件InitLoadPreRender事件执行顺序：1)控件的Init事件2)控件所在页面的Init事件3)控件所在页面的Load事件4)控件的Load事件5)控件所在页面的PreRender事件6)控件的PreRender事件规律：1)Init事件从最里面的控件(包括用户控件及普通控件)向最外面的控件(页面)引发，Load及PreRender等其他事件从最外面的控件向最里面的控件引发；2)控件之间相同事件的执行顺序依控件在页面的位置按从左到右，从上到下的先后顺序执行。注意：1)切记用户控件也被视为页面中的一个控件；2)把用户控件作为单独的一个特殊页面来看，它本身及其所包含的控件同样遵守相同的规律；3)有时在客户端程序(如javascript)中会用到客户端body对像的onload事件，注意这个客户端事件是最后执行，即在服务器端所有事件执行完后才执行。=转载一篇关于页面对象模型的文章，说得比较详细，有助理解。没事的时候就多看两遍，慢慢体会：)。ASP.NET页面对象模型Dino Esposito Wintellect 2003年8月适用于：Microsoft(R)ASP.NET摘要：了解为ASP.NETWeb页面建立的事件模型，以及Web页面转变为HTML过程中的各个阶段。ASP.NETHTTP运行时负责管理对象管道，这些对象首先将请求的URL转换成Page类的具体实例，然后再将这些实例转换成纯HTML文本。本文将探讨那些作为页面生命周期标志的事件，以及控件和页面编写者如何干预并改变标准行为。(本文包含一些指向英文站点的链接。)目录简介真正的Page类页面的生命周期执行的各个阶段小结简介对由Microsoft(R)Internet信息服务(IIS)处理的Microsoft(R)ASP.NET页面的每个请求都会被移交到ASP.NETHTTP管道。HTTP管道由一系列托管对象组成，这些托管对象按顺序处理请求，并将URL转换为纯HTML文本。HTTP管道的入口是HttpRuntime类。ASP.NET结构为辅助进程中的每个AppDomain创建一个此类的实例。(请注意，辅助进程为每个当前正在运行的ASP.NET应用程序维护一个特定的AppDomain。)HttpRuntime类从内部池中获取HttpApplication对象，并安排此对象来处理请求。HTTP应用程序管理器完成的主要任务就是找到将真正处理请求的类。当请求.aspx资源时，处理程序就是页面处理程序，即从Page继承的类的实例。资源类型和处理程序类型之间的关联关系存储在应用程序的配置文件中。更确切地说，默认的映射集是在machine.config文件的部分定义的。但是，应用程序可以在本地的web.config文件中自定义自己的HTTP处理程序列表。以下这一行代码就是用来为.aspx资源定义HTTP处理程序的。扩展名可以与处理程序类相关联，并且更多是与处理程序工厂类相关联。在所有情况下，负责处理请求的HttpApplication对象都会获得一个实现IHttpHandler接口的对象。如果根据HTTP处理程序来解析关联的资源/类，则返回的类将直接实现接口。如果资源被绑定到处理程序工厂，则还需要额外的步骤。处理程序工厂类实现IHttpHandlerFactory接口，此接口的GetHandler方法将返回一个基于IHttpHandler的对象。HTTP运行时是如何结束这个循环并处理页面请求的?ProcessRequest方法在IHttpHandler接口中非常重要。通过对代表被请求页面的对象调用此方法，ASP.NET结构会启动将生成浏览器输出的进程。真正的Page类特定页面的HTTP处理程序类型取决于URL。首次调用URL时，将构建一个新的类，这个类被动态编译为一个程序集。检查.aspx资源的分析进程的结果是类的源代码。该类被定义为命名空间ASP的组成部分，并且被赋予了一个模拟原始URL的名称。例如，如果URL的终点是page.aspx，则类的名称就是ASP.Page_aspx。不过，类的名称可以通过编程方式来控制，方法是在Page指令中设置ClassName属性。HTTP处理程序的基类是Page。这个类定义了由所有页面处理程序共享的方法和属性的最小集合。Page类实现IHttpHandler接口。在很多情况下，实际处理程序的基类并不是Page，而是其他的类。例如，如果使用了代码分离，就会出现这种情况。代码分离是一项开发技术，它可以将页面所需的代码隔离到单独的C#和Microsoft Visual Basic(R).NET类中。页面的代码是一组事件处理程序和辅助方法，这些处理程序和方法真正决定了页面的行为。可以使用标记对此代码进行内联定义，或者将其放置在外部类(代码分离类)中。代码分离类是从Page继承并使用额外的方法的类，被指定用作HTTP处理程序的基类。还有一种情况，HTTP处理程序也不是基于Page的，即在应用程序配置文件的部分中，包含了PagebaseType属性的重新定义。PagebaseType属性指明包含页面处理程序的基类的类型和程序集。从Page导出的这个类可以自动赋予处理程序扩展的自定义方法和属性集。页面的生命周期完全识别HTTP页面处理程序类后，ASP.NET运行时将调用处理程序的ProcessRequest方法来处理请求。通常情况下，无需更改此方法的实现，因为它是由Page类提供的。此实现将从调用为页面构建控件树的frameworkInitialize方法开始。frameworkInitialize方法是TemplateControl类(Page本身从此类导出)的一个受保护的虚拟成员。所有为.aspx资源动态生成的处理程序都将覆盖frameworkInitialize。在此方法中，构建了页面的整个控件树。接下来，ProcessRequest使页面经历了各个阶段：初始化、加载视图状态信息和回发数据、加载页面的用户代码以及执行回发服务器端事件。之后，页面进入显示模式：收集更新的视图状态，生成HTML代码并随后将代码发送到输出控制台。最后，卸载页面，并认为请求处理完毕。在各个阶段中，页面会触发少数几个事件，这些事件可以由Web控件和用户定义的代码截取并进行处理。其中的一些事件是嵌入式控件专用的，因此无法在.aspx代码级进行处理。要处理特定事件的页面应该明确注册一个适合的处理程序。不过，为了向后兼容早期的Visual Basic编程风格，ASP.NET也支持隐式事件挂钩的形式。默认情况下，页面会尝试将特定的方法名称与事件相匹配，如果实现匹配，则认为此方法就是匹配事件的处理程序。ASP.NET提供了六种方法名称的特定识别，它们是Page_Init、Page_Load、Page_DataBind、Page_PreRender和Page_Unload。这些方法被认为是由Page类提供的相应事件的处理程序。HTTP运行时会自动将这些方法绑定到页面事件，这样，开发人员就不必再编写所需的粘接代码了。例如，如果命名为Page_Load的方法绑定到页面的Load事件，则可省去以下代码。this.Load+=new EventHandler(this.Page_Load)；对特定名称的自动识别是由Page指令的AutoEventWireup属性控制的。如果该属性设置为false，则要处理事件的所有应用程序都需要明确连接到页面事件。不使用自动绑定事件的页面性能会稍好一些，因为不需要额外匹配名称与事件。请注意，所有Microsoft Visual Studio(R).NET项目都是在禁用AutoEventWireup属性的情况下创建的。但是，该属性的默认设置是true，即Page_Load等方法会被识别，并被绑定到相关联的事件。下表中按顺序列出了页面的执行包括的几个阶段，执行的标志是一些应用程序级的事件和/或受保护并可覆盖的方法。表1：ASP.NET页面生命中的关键事件阶段页面事件可覆盖的方法页面初始化Init加载视图状态LoadViewState处理回发数据任意实现IPostBackDataHandler接口的控件中的LoadPostData方法加载页面Load回发更改通知任意实现IPostBackDataHandler接口的控件中的RaisePostDataChangedEvent方法处理回发事件由控件定义的任意回发事件任意实现IPostBackDataHandler接口的控件中的RaisePostBackEvent方法页面显示前阶段PreRender保存视图状态SaveViewState显示页面Render卸载页面Unload以上所列的阶段中有些在页面级是不可见的，并且仅对服务器控件的编写者和要创建从Page导出的类的开发人员有意义。Init、Load、PreRender、Unload，再加上由嵌入式控件定义的所有回发事件，就构成了向外发送页面的各个阶段标记。执行的各个阶段页面生命周期中的第一个阶段是初始化。这个阶段的标志是Init事件。在成功创建页面的控件树后，将对应用程序触发此事件。换句话说，当Init事件发生时，.aspx源文件中静态声明的所有控件都已实例化并采用各自的默认值。控件可以截取Init事件以初始化在传入的Web请求的生命周期内所需的所有设置。例如，这时控件可以加载外部模板文件或设置事件的处理程序。请注意，这时视图状态信息尚不可用。初始化之后，页面框架将加载页面的视图状态。视图状态是名称/值对的集合，在此集合中，控件和页面本身存储了对所有Web请求都必须始终有效的全部信息。视图状态代表了页面的调用上下文。通常，它包含上次在服务器上处理页面时控件的状态。首次在会话中请求页面时，视图状态为空。默认情况下，视图状态存储在静默添加到页面的隐藏字段中，该字段的名称是_VIEWSTATE。通过覆盖LoadViewState方法(Control类的受保护、可覆盖方法)，组件开发人员可以控制视图状态的存储方式以及视图状态的内容映射到内部状态的方式。有些方法(如LoadPageStateFromPersistenceMedium以及其对应的SavePageStateToPersistenceMedium)，可以用来将视图状态加载并保存到其他存储介质(例如会话、数据库或服务器端文件)中。与LoadViewState不同，上述方法只能在从Page导出的类中使用。存储视图状态之后，页面树中控件的状态与页面最后一次显示在浏览器中的状态相同。下一步是更新它们的状态以加入客户端的更改。处理回发数据阶段使控件有机会更新其状态，从而准确反映客户端相应的HTML元素的状态。例如，服务器的TextBox控件对应的HTML元素是。在回发数据阶段，TextBox控件将检索标记的当前值，并使用该值来刷新自己内部的状态。每个控件都要从回发的数据中提取值并更新自己的部分属性。TextBox控件将更新它的Text属性，而CheckBox控件将刷新它的Checked属性。服务器控件和HTML元素的对应关系可以通过二者的ID找到。在处理回发数据阶段的最后，页面中的所有控件的状态都将使用客户端输入的更改来更新前一状态。这时，将对页面触发Load事件。页面中可能会有一些控件，当其某个敏感属性在两个不同的请求中被修改时，需要完成特定的任务。例如，如果TextBox控件的文本在客户端被修改，则此控件将触发TextChanged事件。每个控件在其一个或多个属性被修改为客户端输入的值时都可以决定触发相应的事件。对于这些更改对其非常关键的控件，控件实现IPostBackDataHandler接口，此接口的LoadPostData方法是在Load事件后立即调用的。通过对LoadPostData方法进行编码，控件将验证自上次请求后是否发生了关键更改，并触发自己的更改事件。页面生命周期中的关键事件是被调用以执行服务器端代码的事件，此代码与客户端触发的事件相关联。当用户单击按钮时，将回发页面。回发值的集合中包括启动整个操作的按钮的ID。如果控件实现IPostBackEventHandler接口(如按钮和链接按钮)，页面框架将