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

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

《母版页与内容页的调用顺序doc.docx》由会员分享，可在线阅读，更多相关《母版页与内容页的调用顺序doc.docx（8页珍藏版）》请在冰豆网上搜索。

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

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

母版页与内容页的调用顺序2011-03-1310：

22

母版页和内容页都可以包含控件的事件处理程序。

对于控件而言，事件是在本地处理的，即内容页中的控件在内容页中引发事件，母版页中的控件在母版页中引发事件。

控件事件不会从内容页发送到母版页。

同样，也不能在内容页中处理来自母版页控件的事件。

在某些情况下，内容页和母版页中会引发相同的事件。

例如，两者都引发Init和Load事件。

引发事件的一般规则是初始化事件从最里面的控件向最外面的控件引发，所有其他事件则从最外面的控件向最里面的控件引发。

请记住，母版页会合并到内容页中并被视为内容页中的一个控件，这一点十分有用。

下面是母版页与内容页合并后事件的发生顺序：

母版页控件Init事件。

内容控件Init事件。

母版页Init事件。

内容页Init事件。

内容页Load事件。

母版页Load事件。

内容控件Load事件。

内容页PreRender事件。

母版页PreRender事件。

母版页控件PreRender事件。

内容控件PreRender事件。

关于中页面事件加载的先后顺序

Page执行中将按照如下顺序激活事件：

Page.PreInitPage.InitPage.InitComplitePage.PreLoadPage.LoadPage.LoadCompletePage.PreRenderPage.PreRenderComplete

如果页面从另一个页面继承，如basePage：

System.Web.UI.Page，在basePage中做了一些扩展，如权限检查，而其他页面从basePage继承，则basePage和最终Page的事件激活顺序是：

UI.PreInitPage.PreInitUI.InitPage.InitUI.InitComplitePage.InitCompliteUI.PreLoadPage.PreLoadUI.LoadPage.LoadUI.LoadCompletePage.LoadCompleteUI.PreRenderPage.PreRenderUI.PreRenderCompletePage.PreRenderComplete

如果使用了MasterPage，则MasterPage中的事件和ContentPage中的事件按照下面顺序激活：

ContentPage.PreInitMaster.InitContentPage.InitContentPage.InitCompliteContentPage.PreLoadContentPage.LoadMaster.LoadContentPage.LoadCompleteContentPage.PreRenderMaster.PreRenderContentPage.PreRenderComplete

更进一步，如果ContentPage继承basePage，那么，各事件的执行顺序将变成：

UI.PreInitContentPage.PreInitMaster.InitUI.InitContentPage.InitUI.InitCompliteContentPage.InitCompliteUI.PreLoadContentPage.PreLoadUI.LoadContentPage.LoadMaster.LoadUI.LoadCompleteContentPage.LoadCompleteUI.PreRenderContentPage.PreRenderMaster.PreRenderUI.PreRenderCompleteContentPage.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_DisposedPage对象从内存中释放掉。

这是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页面对象模型

DinoEspositoWintellect2003年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#和MicrosoftVisualBasic（R）.NET类中。

页面的代码是一组事件处理程序和辅助方法，这些处理程序和方法真正决定了页面的行为。

可以使用标记对此代码进行内联定义，或者将其放置在外部类（代码分离类）中。

代码分离类是从Page继承并使用额外的方法的类，被指定用作HTTP处理程序的基类。

还有一种情况，HTTP处理程序也不是基于Page的，即在应用程序配置文件的部分中，包含了PagebaseType属性的重新定义。

PagebaseType属性指明包含页面处理程序的基类的类型和程序集。

从Page导出的这个类可以自动赋予处理程序扩展的自定义方法和属性集。

页面的生命周期

完全识别HTTP页面处理程序类后，ASP.NET运行时将调用处理程序的ProcessRequest方法来处理请求。

通常情况下，无需更改此方法的实现，因为它是由Page类提供的。

此实现将从调用为页面构建控件树的frameworkInitialize方法开始。

frameworkInitialize方法是TemplateControl类（Page本身从此类导出）的一个受保护的虚拟成员。

所有为.aspx资源动态生成的处理程序都将覆盖frameworkInitialize。

在此方法中，构建了页面的整个控件树。

接下来，ProcessRequest使页面经历了各个阶段：

初始化、加载视图状态信息和回发数据、加载页面的用户代码以及执行回发服务器端事件。

之后，页面进入显示模式：

收集更新的视图状态，生成HTML代码并随后将代码发送到输出控制台。

最后，卸载页面，并认为请求处理完毕。

在各个阶段中，页面会触发少数几个事件，这些事件可以由Web控件和用户定义的代码截取并进行处理。

其中的一些事件是嵌入式控件专用的，因此无法在.aspx代码级进行处理。

要处理特定事件的页面应该明确注册一个适合的处理程序。

不过，为了向后兼容早期的VisualBasic编程风格，ASP.NET也支持隐式事件挂钩的形式。

默认情况下，页面会尝试将特定的方法名称与事件相匹配，如果实现匹配，则认为此方法就是