ASPNET页面事件执行过程_第1页
ASPNET页面事件执行过程_第2页
ASPNET页面事件执行过程_第3页
ASPNET页面事件执行过程_第4页
ASPNET页面事件执行过程_第5页
已阅读5页,还剩4页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、.:.;ASP.NET 母版页和内容页中的事件母版页和内容页都可以包含控件的事件处置程序。对于控件而言,事件是在本地处置的,即内容页中的控件在内容页中引发事件,母版页中的控件在母版页中引发事件。控件事件不会从内容页发送到母版页。同样,也不能在内容页中处置母版页控件的事件。在某些情况下,内容页和母版页中会引发一样的事件。例如,两者都引发 HYPERLINK msdn.microsoft/zh-cn/library/system.web.ui.control.init.aspxInit 和 HYPERLINK msdn.microsoft/zh-cn/library/system.web.ui.c

2、ontrol.load.aspxLoad 事件。引发事件的普通规那么是初始化事件从最里面的控件向最外面的控件引发,一切其他事件那么从最外面的控件向最里面的控件引发。请记住,母版页会合并到内容页中并被视为内容页中的一个控件,这一点非常有用。下面是母版页与内容页合并后事件的发生顺序:母版页控件 Init 事件。内容控件 Init 事件。母版页 Init 事件。内容页 Init 事件。内容页 Load 事件。母版页 Load 事件。内容控件 Load 事件。内容页 PreRender 事件。母版页 PreRender 事件。母版页控件 PreRender 事件。内容控件 PreRender 事件。母

3、版页和内容页中的事件顺序对于页面开发人员并不重要。但是,假设您创建的事件处置程序取决于某些事件的可用性,那么您将发现,了解母版页和内容页中的事件顺序很有协助 。HYPERLINK cnblogs/Kevan/archive/2021/06/26/1230384.html关于中页面事件加载的先后顺序 Page 执行中将按照如下顺序激活事件:Page.PreInitPage.InitPage.InitComplitePage.PreLoadPage.LoadPage.LoadCompletePage.PreRenderPage.PreRenderComplete假设页面从另一个页面承继,如Base

4、Page: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假设

5、运用了MasterPage,那么MasterPage中的事件和ContentPage中的事件按照下面顺序激活:ContentPage.PreInitMaster.InitContentPage.InitContentPage.InitCompliteContentPage.PreLoadContentPage.LoadMaster.LoadContentPage.LoadCompleteContentPage.PreRenderMaster.PreRenderContentPage.PreRenderComplete更进一步,假设ContentPage承继BasePage,那么,各事件的执行顺

6、序将变成:UI.PreInitContentPage.PreInitMaster.InitUI.InitContentPage.InitUI.InitCompliteContentPage.InitCompliteUI.PreLoadContentPage.PreLoadUI.LoadContentPage.LoadMaster.LoadUI.LoadCompleteContentPage.LoadCompleteUI.PreRenderContentPage.PreRenderMaster.PreRenderUI.PreRenderCompleteContentPage.PreRenderC

7、omplete阅读下来发现并不是我如今所学的 1.1,估计应该是 2.0,不过也没有关系,这让我知道了他们有承继时加载的顺序。即:先加载承继页的,再加载本人的,假设承继页有承继那么先加载承继页的承继。其实是个很简单的内容。顺便写下Page事件不知道1.1是不是就这些事件处置器称号发生时间Page_Init在Web窗体的视图形状加载效力器控件并对其初始化。这是web窗体生命周期的第一步 Page_Load在Page对象上载入效力器控件。由于此时视图形状信息是可以运用的,因此载这里可以用代码来改动空间的设置或者载页面上显示文本。 Page_PreRender 运用程序将要呈现Page对象 Page

8、_Unload 页面从内存中卸载 Page_Error发生未处置的异常Page_AbortTransaction 事务处置被终止 Page_CommitTransaction 事务处置被接受 Page_DataBinding 把页面上的效力器空间和数据源绑定载一同 Page_DisposedPage对象从内存中释放掉。这是Page对象生命周期中的最后一个事件 Init,Load,PreRender事件执行顺序:1控件的Init事件2控件所在页面的Init事件3控件所在页面的Load事件4控件的Load事件5控件所在页面的PreRender事件6控件的PreRender事件规律:1Init事件从

9、最里面的控件包括用户控件及普通控件向最外面的控件页面引发,Load及PreRender等其他事件从最外面的控件向最里面的控件引发;2控件之间一样事件的执行顺序依控件在页面的位置按从左到右,从上到下的先后顺序执行。留意:1切记用户控件也被视为页面中的一个控件;2把用户控件作为单独的一个特殊页面来看,它本身及其所包含的控件同样遵守一样的规律;3有时在客户端程序如javascript中会用到客户端body对像的onload事件,留意这个客户端事件是最后执行,即在效力器端一切事件执行完后才执行。测试环境:Windows2000 Pro+IIS5.0+Dotnet Framework1.1=转载一篇关于

10、页面对象模型的文章,说得比较详细,有助了解。没事的时候就多看两遍,渐渐领会:)。ASP.NET 页面对象模型Dino EspositoWintellect 2003 年 8 月适用于: Microsoft ASP.NET 摘要:了解为 ASP.NET Web 页面建立的事件模型,以及 Web 页面转变为 HTML 过程中的各个阶段。ASP.NET 运转时担任管理对象管道,这些对象首先将恳求的 URL 转换成 Page 类的详细实例,然后再将这些实例转换成纯 HTML 文本。本文将讨论那些作为页面生命周期标志的事件,以及控件和页面编写者如何干涉并改动规范行为。本文包含一些指向英文站点的链接。目录

11、简介真正的 Page 类页面的生命周期执行的各个阶段小结简介 对由 Microsoft Internet 信息效力 (IIS) 处置的 Microsoft ASP.NET 页面的每个恳求都会被移交到 ASP.NET 管道。 管道由一系列托管对象组成,这些托管对象按顺序处置恳求,并将 URL 转换为纯 HTML 文本。 管道的入口是 HttpRuntime 类。ASP.NET 构造为辅助进程中的每个 AppDomain 创建一个此类的实例。请留意,辅助进程为每个当前正在运转的 ASP.NET 运用程序维护一个特定的 AppDomain。HttpRuntime 类从内部池中获取 HttpAppli

12、cation 对象,并安排此对象来处置恳求。 运用程序管理器完成的主要义务就是找到将真正处置恳求的类。当恳求 .aspx 资源时,处置程序就是页面处置程序,即从 Page 承继的类的实例。资源类型和处置程序类型之间的关联关系存储在运用程序的配置文件中。更确切地说,默许的映射集是在 machine.config 文件的 部分定义的。但是,运用程序可以在本地的 web.config 文件中自定义本人的 处置程序列表。以下这一行代码就是用来为 .aspx 资源定义 处置程序的。 扩展名可以与处置程序类相关联,并且更多是与处置程序工厂类相关联。在一切情况下,担任处置恳求的 HttpApplicatio

13、n 对象都会获得一个实现 IHttpHandler 接口的对象。假设根据 处置程序来解析关联的资源/类,那么前往的类将直接实现接口。假设资源被绑定四处置程序工厂,那么还需求额外的步骤。处置程序工厂类实现 IHttpHandlerFactory 接口,此接口的 GetHandler 方法将前往一个基于 IHttpHandler 的对象。 运转时是如何终了这个循环并处置页面恳求的?ProcessRequest 方法在 IHttpHandler 接口中非常重要。经过对代表被恳求页面的对象调用此方法,ASP.NET 构造会启动将生成阅读器输出的进程。真正的 Page 类 特定页面的 处置程序类型取决于

14、 URL。初次调用 URL 时,将构建一个新的类,这个类被动态编译为一个程序集。检查 .aspx 资源的分析进程的结果是类的源代码。该类被定义为命名空间 ASP 的组成部分,并且被赋予了一个模拟原始 URL 的称号。例如,假设 URL 的终点是 page.aspx,那么类的称号就是 ASP.Page_aspx。不过,类的称号可以经过编程方式来控制,方法是在 Page 指令中设置 ClassName 属性。 处置程序的基类是 Page。这个类定义了由一切页面处置程序共享的方法和属性的最小集合。Page 类实现 IHttpHandler 接口。在很多情况下,实践处置程序的基类并不是 Page,而是

15、其他的类。例如,假设运用了代码分别,就会出现这种情况。代码分别是一项开发技术,它可以将页面所需的代码隔离到单独的 C# 和 Microsoft Visual Basic .NET 类中。页面的代码是一组事件处置程序和辅助方法,这些处置程序和方法真正决议了页面的行为。可以运用 标志对此代码进展内联定义,或者将其放置在外部类代码分别类中。代码分别类是从 Page 承继并运用额外的方法的类,被指定用作 处置程序的基类。还有一种情况, 处置程序也不是基于 Page 的,即在运用程序配置文件的 部分中,包含了 PageBaseType 属性的重新定义。 PageBaseType 属性指明包含页面处置程序

16、的基类的类型和程序集。从 Page 导出的这个类可以自动赋予处置程序扩展的自定义方法和属性集。页面的生命周期 完全识别 页面处置程序类后,ASP.NET 运转时将调用途置程序的 ProcessRequest 方法来处置恳求。通常情况下,无需更改此方法的实现,由于它是由 Page 类提供的。此实现将从调用为页面构建控件树的 FrameworkInitialize 方法开场。FrameworkInitialize 方法是 TemplateControl 类Page 本身从此类导出的一个受维护的虚拟成员。一切为 .aspx 资源动态生成的处置程序都将覆盖 FrameworkInitialize。在此

17、方法中,构建了页面的整个控件树。接下来,ProcessRequest 使页面阅历了各个阶段:初始化、加载视图形状信息和回发数据、加载页面的用户代码以及执行回发效力器端事件。之后,页面进入显示方式:搜集更新的视图形状,生成 HTML 代码并随后将代码发送到输出控制台。最后,卸载页面,并以为恳求处置终了。在各个阶段中,页面会触发少数几个事件,这些事件可以由 Web 控件和用户定义的代码截取并进展处置。其中的一些事件是嵌入式控件公用的,因此无法在 .aspx 代码级进展处置。要处置特定事件的页面应该明确注册一个适宜的处置程序。不过,为了向后兼容早期的 Visual Basic 编程风格,ASP.NE

18、T 也支持隐式事件挂钩的方式。默许情况下,页面会尝试将特定的方法称号与事件相匹配,假照实现匹配,那么以为此方法就是匹配事件的处置程序。ASP.NET 提供了六种方法称号的特定识别,它们是 Page_Init、Page_Load、Page_DataBind、Page_PreRender 和 Page_Unload。这些方法被以为是由 Page 类提供的相应事件的处置程序。 运转时会自动将这些方法绑定到页面事件,这样,开发人员就不用再编写所需的粘接代码了。例如,假设命名为 Page_Load 的方法绑定到页面的 Load 事件,那么可省去以下代码。this.Load += new EventHan

19、dler(this.Page_Load); 对特定称号的自动识别是由 Page 指令的 AutoEventWireup 属性控制的。假设该属性设置为 false,那么要处置事件的一切运用程序都需求明确衔接到页面事件。不运用自动绑定事件的页面性能会稍好一些,由于不需求额外匹配称号与事件。请留意,一切 Microsoft Visual Studio .NET 工程都是在禁用 AutoEventWireup 属性的情况下创建的。但是,该属性的默许设置是 true,即 Page_Load 等方法会被识别,并被绑定到相关联的事件。下表中按顺序列出了页面的执行包括的几个阶段,执行的标志是一些运用程序级的事

20、件和/或受维护并可覆盖的方法。表 1:ASP.NET 页面生命中的关键事件阶段页面事件可覆盖的方法页面初始化Init加载视图形状LoadViewState处置回发数据恣意实现 IPostBackDataHandler 接口的控件中的 LoadPostData 方法加载页面Load回发更改通知恣意实现 IPostBackDataHandler 接口的控件中的 RaisePostDataChangedEvent 方法处置回发事件由控件定义的恣意回发事件恣意实现 IPostBackDataHandler 接口的控件中的 RaisePostBackEvent 方法页面显示前阶段PreRender保管视

21、图形状SaveViewState显示页面Render卸载页面Unload以上所列的阶段中有些在页面级是不可见的,并且仅对效力器控件的编写者和要创建从 Page 导出的类的开发人员有意义。Init、Load、PreRender、Unload,再加上由嵌入式控件定义的一切回发事件,就构成了向外发送页面的各个阶段标志。执行的各个阶段 页面生命周期中的第一个阶段是初始化。这个阶段的标志是 Init 事件。在胜利创建页面的控件树后,将对运用程序触发此事件。换句话说,当 Init 事件发生时,.aspx 源文件中静态声明的一切控件都已实例化并采用各自的默许值。控件可以截取 Init 事件以初始化在传入的

22、Web 恳求的生命周期内所需的一切设置。例如,这时控件可以加载外部模板文件或设置事件的处置程序。请留意,这时视图形状信息尚不可用。初始化之后,页面框架将加载页面的视图形状。视图形状是称号/值对的集合,在此集合中,控件和页面本身存储了对一切 Web 恳求都必需一直有效的全部信息。视图形状代表了页面的调用上下文。通常,它包含上次在效力器上处置页面时控件的形状。初次在会话中恳求页面时,视图形状为空。默许情况下,视图形状存储在静默添加到页面的隐藏字段中,该字段的称号是 _VIEWSTATE。经过覆盖 LoadViewState 方法Control 类的受维护、可覆盖方法,组件开发人员可以控制视图形状的

23、存储方式以及视图形状的内容映射到内部形状的方式。有些方法如 LoadPageStateFromPersistenceMedium 以及其对应的 SavePageStateToPersistenceMedium,可以用来将视图形状加载并保管到其他存储介质例如会话、数据库或效力器端文件中。与 LoadViewState 不同,上述方法只能在从 Page 导出的类中运用。存储视图形状之后,页面树中控件的形状与页面最后一次显示在阅读器中的形状一样。下一步是更新它们的形状以参与客户端的更改。处置回发数据阶段使控件有时机更新其形状,从而准确反映客户端相应的 HTML 元素的形状。例如,效力器的 TextB

24、ox 控件对应的 HTML 元素是 。在回发数据阶段,TextBox 控件将检索 标志的当前值,并运用该值来刷新本人内部的形状。每个控件都要从回发的数据中提取值并更新本人的部分属性。TextBox 控件将更新它的 Text 属性,而 CheckBox 控件将刷新它的 Checked 属性。效力器控件和 HTML 元素的对应关系可以经过二者的 ID 找到。在处置回发数据阶段的最后,页面中的一切控件的形状都将运用客户端输入的更改来更新前一形状。这时,将对页面触发 Load 事件。页面中能够会有一些控件,当其某个敏感属性在两个不同的恳求中被修正时,需求完成特定的义务。例如,假设 TextBox 控件的文本在客户端被修正,那么此控件将触发 TextChanged 事件。每个控件在其一个或多个属性被修正为客户端输入的值时都可以决议触发相应的事件。对于这些更改对其非常关键的控件,控件实现 IPostBackDataHandler 接口,此接口的 LoadPostData 方法是在 Load 事件后立刻调用的。经过对 LoadPostData 方法进展编码,控件将验证自上次恳求后能否发生了关键更改,并触发本人的更改事件。页面生命周期中的关键事件是被调用以执行效力器端代码的事件,此代码与客户端触发的事件相关联。当用户单击按钮时,将回

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论