C#城市公交查询系统(文献综述+外文文献翻译+源程序) 第4页
the ID of both.
At the end of the postback data processing stage, all controls in the page reflect the previous state updated with changes entered on the client. At this point, the Load event is fired to the page.
There might be controls in the page that need to accomplish certain tasks if a sensitive property is modified across two different requests. For example, if the text of a textbox control is modified on the client, the control fires the TextChanged event. Each control can take the decision to fire an appropriate event if one or more of its properties are modified with the values coming from the client. Controls for which these changes are critical implement the IPostBackDataHandler interface, whose LoadPostData method is invoked immediately after the Load event. By coding the LoadPostData method, a control verifies if any critical change has occurred since last request and fires its own change event.
The key event in the lifecycle of a page is when it is called to execute the server-side code associated with an event triggered on the client. When the user clicks a button, the page posts back. The collection of posted values contains the ID of the button that started the whole operation. If the control is known to implement the IPostBackEventHandler interface (buttons and link buttons will do), the page framework calls the RaisePostBackEvent method. What this method does depends on the type of the control. With regard to buttons and link buttons, the method looks up for a Click event handler and runs the associated delegate.
After handling the postback event, the page prepares for rendering. This stage is signaled by the Pretender event. This is a good time for controls to perform any last minute update operations that need to take place immediately before the view state is saved and the output rendered. The next state is SaveViewState, in which all controls and the page itself are invited to flush the contents of their own ViewState collection. The resultant view state is then serialized, hashed, Base64 encoded, and associated with the __VIEWSTATE hidden field.
The rendering mechanism of individual controls can be altered by overriding the Render method. The method takes an HTML writer object and uses it to accumulate all HTML text to be generated for the control. The default implementation of the Render method for the Page class consists of a recursive call to all constituent controls. For each control the page calls the Render method and caches the HTML output.
The final sign of life of a page is the Unload event that arrives just before the page object is dismissed. In this event you should release any critical resource you might have (for example, files, graphical objects, database connections).
Finally, after this event the browser receives the HTTP response packet and displays the page.
Summary
The ASP.NET page object model is particularly innovative because of the eventing mechanism. A Web page is composed of controls that both produce a rich HTML-based user interface and interact with the user through events. Setting up an eventing model in the context of Web applications is challenging. It's amazing to see that client-side generated events are resolved with server-side code, and the output of this is visible as the same HTML page, only properly modified.
To make sense of this model it is important to understand the various stages in the page lifecycle and how the page object is instantiated and used by the HTTP run time.
译成中文：
[ASP.NET 页面对象模型：]
摘要：了解围绕 ASP.NET Web 页构建的事件模型，以及一个 Web 页面在其转变为 HTML 的历程中的各个阶段。ASP.NET HTTP 运行时控制对象管线，对象管线首先将所请求的 URL 转换为一个页面类的活动实例，然后将其转
www.youerw.com 信息服务 (IIS) 所收到的对某 Microsoft ASP.NET 页面的每个请求都被移交给 ASP.NET HTTP 管线。HTTP 管线由一系列托管对象组成，这些对象按顺序处理该请求，并完成从 URL 到普通 HTML 文本的转换。HTTP 管线的入口点是 HttpRuntime 类。ASP.NET 基础结构为辅助进程中所承载的每个 AppDomain 创建此类的一个实例（请注意，该辅助进程为当前正在运行的每个 ASP.NET 应用程序文护一个不同的 AppDomain）。
HttpRuntime 类从内部池中选取一个 HttpApplication 对象，并让其处理该请求。HTTP 应用程序管理器所完成的主要任务就是找出将实际处理该请求的类。如果请求 .aspx 资源，则处理程序就是一个页面处理程序 — 即某个继承自 Page 的类的一个实例。资源类型和处理程序类型之间的关联关系存储于该应用程序的配置文件中。更准确地说，在 machine.config 文件的 <httpHandlers> 部分中定义默认的一组映射关系。然而，应用程序也可以在本地的 web.config 文件中自定义自己的 HTTP 处理程序列表。下面的程序行举例说明了定义用于 .aspx 资源的 HTTP 处理程序的代码。<add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory"/>扩展名可关联到一个处理程序类，或者更普遍地关联到一个处理程序工厂 (handler factory) 类。在所有情况下，负责处理请求的 HttpApplication 对象都会获得一个实现 IHttpHandler 接口的对象。如果根据 HTTP 处理程序来解析关联资源/类，那么所返回的类将直接实现该接口。如果资源绑定到处理程序工厂，则需要另外一个步骤。处理程序工厂类实现 IHttpHandlerFactory 接口，而该接口的 GetHandler 方法返回一个基于 IHttpHandler 的对象。
HTTP 运行时如何能完成整个循环并处理页面请求呢？IHttpHandler 接口特别提供了 ProcessRequest 方法。通过对代表所请求页面的对象调用此方法，ASP.NET 基础结构启动相应过程，从而针对浏览器生成输出。
真正的 Page 类
特定页面的 HTTP 处理程序类型取决于 URL。当首次调用 URL 时，将构建一个新类并将该类动态地编译成一个程序集。用于检查 .aspx 来源的语法分析过程的输出结果就是该类的源代码。该类被定义为 ASP 命名空间的一部分，并被赋予一个与原始 URL 相似的名称。例如，如果 URL 终结点是 page.aspx，则类名称为 ASP.Page_aspx。但是，也可通过编程设置 @Page 指令的 ClassName 属性来控制类的名称。
HTTP 处理程序的基类是 Page。此类定义了所有页面处理程序所共享的方法和属性的最小集合。Page 类中实现 IHttpHandler 接口。
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>
C#城市公交查询系统(文献综述+外文文献翻译+源程序) 第4页下载如图片无法显示或论文不完整，请联系qq752018766
