附录 1 英文原文
Introduction to https://www.doczj.com/doc/a89822401.html, Pages and Inline Code and Share[10] The https://www.doczj.com/doc/a89822401.html, Web Forms page framework is a scalable common language runtime programming model that can be used on the server to dynamically generate Web pages. Intended as a logical evolution of ASP (https://www.doczj.com/doc/a89822401.html, provides syntax compatibility with existing pages), the https://www.doczj.com/doc/a89822401.html, page framework has been specifically designed to address a number of key deficiencies in the previous model. In particular, it provides the ability to create and use reusable UI controls that can encapsulate common functionality and thus reduce the amount of code that a page developer has to write, the ability for developers to cleanly structure their page logic in an orderly fashion (not "spaghetti code"), and the ability for development tools to provide strong WYSIWYG design support for pages (existing classic ASP code is opaque to tools). This section of the QuickStart provides a high-level code walkthrough of some basic https://www.doczj.com/doc/a89822401.html, page features. Subsequent sections of the QuickStart drill down into more specific details. https://www.doczj.com/doc/a89822401.html, pages are text files with an .htm file name extension. Pages consist of code and markup and are dynamically compiled and executed on the server to produce a rendering to the requesting client browser (or device). They can be deployed throughout an IIS virtual root directory tree. When a browser client requests .htm resources, the https://www.doczj.com/doc/a89822401.html, runtime parses and compiles the target file into a .NET Framework class. This class can then be used to dynamically process incoming requests. (Note that the .htm file is compiled only the first time it is accessed; the compiled type instance is then reused across multiple requests).
An https://www.doczj.com/doc/a89822401.html, page can be created simply by taking an existing HTML file and changing its file name extension to .htm (no modification of code is required). For example, the following sample demonstrates a simple HTML page that collects a user's name and category preference and then performs a form postback to the originating page when a button is clicked:
Important: Note that nothing happens yet when you click the Lookup button. This
is because the .htm file contains only static HTML (no dynamic content). Thus, the same HTML is sent back to the client on each trip to the page, which results in a loss of the contents of the form fields (the text box and drop-down list) between requests.
https://www.doczj.com/doc/a89822401.html, provides syntax compatibility with existing ASP pages. This includes support for <% %> code render blocks that can be intermixed with HTML content within an .htm file. These code blocks execute in a top-down manner at page render time.
The below example demonstrates how <% %> render blocks can be used to loop over an HTML block (increasing the font size each time):
Important: Unlike with ASP, the code used within the above <% %> blocks is actually compiled--not interpreted using a script engine. This results in improved runtime execution performance.
https://www.doczj.com/doc/a89822401.html, page developers can utilize <% %> code blocks to dynamically modify HTML output much as they can today with ASP. For example, the following sample demonstrates how <% %> code blocks can be used to interpret results posted back from a client.
Important: While <% %> code blocks provide a powerful way to custom manipulate the text output returned from an https://www.doczj.com/doc/a89822401.html, page, they do not provide a clean HTML programming model. As the sample above illustrates, developers using only <% %> code blocks must custom manage page state between round trips and custom interpret posted values.
In addition to code and markup, https://www.doczj.com/doc/a89822401.html, pages can contain server controls, which are programmable server-side objects that typically represent a UI element in the page, such as a textbox or image. Server controls participate in the execution of the page and produce their own markup rendering to the client. The principle advantage of server controls is that they enable developers to get complex rendering and behaviors from simple building-block components, dramatically reducing the amount of code it takes to produce a dynamic Web page. Another advantage of server controls is that it is easy to customize their
rendering or behavior. Server controls expose properties that can be set either declaratively (on the tag) or programmatically (in code). Server controls (and the page itself) also expose events that developers can handle to perform specific actions during the page execution or in response to a client-side action that posts the page back to the server (a "postback"). Server controls also simplify the problem of retaining state across round-trips to the server, automatically retaining their values across successive postbacks.
Server controls are declared within an .htm file using custom tags or intrinsic HTML tags that contain a runat="server" attribute value. Intrinsic HTML tags are handled by one of the controls in the System.Web.UI.HtmlControls namespace. Any tag that doesn't explicitly map to one of the controls is assigned the type of System.Web.UI.HtmlControls.HtmlGenericControl.
Important: Note that these server controls automatically maintain any
client-entered values between round trips to the server. This control state is not stored on the server (it is instead stored within an form field that is round-tripped between requests). Note also that no client-side script is required.
In addition to supporting standard HTML input controls, https://www.doczj.com/doc/a89822401.html, enables developers to utilize richer custom controls on their pages. For example, the following sample demonstrates how the
Each https://www.doczj.com/doc/a89822401.html, server control is capable of exposing an object model containing properties, methods, and events. https://www.doczj.com/doc/a89822401.html, developers can use this object model to cleanly modify and interact with the page.
Note, however, how much cleaner and easier the code is in this new server-control-based version. As we will see later in the tutorial, the https://www.doczj.com/doc/a89822401.html, page Framework also exposes a variety of page-level events that you can handle to write code to execute a specific time during the processing of the page. Examples of these events are Page_Load and Page_Render.
The example below demonstrates a simple https://www.doczj.com/doc/a89822401.html, page with three server
controls, a TextBox, Button, and a Label. Initially these controls just render their HTML form equivalents. However, when a value is typed in the TextBox and the Button is clicked on the client, the page posts back to the server and the page handles this click event in the code of the page, dynamically updating the Text property of the Label control. The page then re-renders to reflect the updated text. This simple example demonstrates the basic mechanics behind the server control model that has made https://www.doczj.com/doc/a89822401.html, one of the easiest Web programming models to learn and master.
Note that in the preceding example the event handler for the Button was located between tags in the same page containing the server controls. https://www.doczj.com/doc/a89822401.html, calls this type of page programming code-inline, and it is very useful when you want to maintain your code and presentation logic in a single file. However, https://www.doczj.com/doc/a89822401.html, also supports another way to factor your code and presentation content, called the code-behind model. When using code-behind, the code for handling events is located in a physically separate file from the page that contains server controls and markup. This clear delineation between code and content is useful when you need to maintain these separately, such as when more than one person is involved in creating the application. It is often common in group projects to have designers working on the UI portions of an application while developers work on the behavior or code. The code-behind model is well-suited to that environment.
https://www.doczj.com/doc/a89822401.html, 2.0 introduces an improved runtime for code-behind pages that simplifies the connections between the page and code. In this new code-behind model, the page is declared as a partial class, which enables both the page and code files to be compiled into a single class at runtime. The page code refers to the code-behind file in the CodeFile attribute of the <%@ Page %>directive, specifying the class name in the Inherits attribute. Note that members of the code behind class must be either public or protected (they cannot be private).
The advantage of the simplified code-behind model over previous versions is that you do not need to maintain separate declarations of server control variables
in the code-behind class. Using partial classes (new in 2.0) allows the server control IDs of the ASPX page to be accessed directly in the code-behind file. This greatly simplifies the maintenance of code-behind pages.
Although you can place code inside each page within your site (using the inline or code-behind separation models described in the previous section), there are times when you will want to share code across several pages in your site. It would be inefficient and difficult to maintain this code by copying it to every page that needs it. Fortunately, https://www.doczj.com/doc/a89822401.html, provides several convenient ways to make code accessible to all pages in an application.
Just as pages can be compiled dynamically at runtime, so can arbitrary code files (for example .cs or .vb files). https://www.doczj.com/doc/a89822401.html, 2.0 introduces the App_Code directory, which can contain standalone files that contain code to be shared across several pages in your application. Unlike https://www.doczj.com/doc/a89822401.html, 1.x, which required these files to be precompiled to the Bin directory, any code files in the App_Code directory will be dynamically compiled at runtime and made available to the application. It is possible to place files of more than one language under the App_Code directory, provided they are partitioned in subdirectories (registered with a particular language in Web.config). The example below demonstrates using the App_Code directory to contain a single class file called from the page.
By default, the App_Code directory can only contain files of the same language. However, you may partition the App_Code directory into subdirectories (each containing files of the same language) in order to contain multiple languages under the App_Code directory. To do this, you need to register each subdirectory in the Web.config file for the application.
Supported in https://www.doczj.com/doc/a89822401.html, version 1, the Bin directory is like the Code directory, except it can contain precompiled assemblies. This is useful when you need to use code that is possibly written by someone other than yourself, where you don't have access to the source code (VB or C# file) but you have a compiled DLL instead. Simply place the assembly in the Bin directory to make it available to your site. By default, all assemblies in the Bin directory are automatically loaded in the app and made accessibe to pages. You may need to Import specific namespaces from assemblies in the Bin directory using the @Import directive at the top of the page.
The .NET Framework 2.0 includes a number of assemblies that represent the various parts of the Framework. These assemblies are stored in the global assembly cache, which is a versioned repository of assemblies made available to all applications on the machine (not just a specific application, as is the case with Bin and App_Code). Several assemblies in the Framework are automatically made available to https://www.doczj.com/doc/a89822401.html, applications. You can register additional assemblies by registration in a Web.config file in your application.
附录 2 中文译文
https://www.doczj.com/doc/a89822401.html,介绍以及内联代码和共享
https://www.doczj.com/doc/a89822401.html, Web 窗体页框架是一种可用于在服务器上动态生成网页的可伸
缩公共语言运行库编程模型。作为ASP的继承和发展，https://www.doczj.com/doc/a89822401.html, 页框架消除了以前ASP中存在的缺陷。尤其是，它提供了创建和使用可封装常用功能的可重用用户界面控件的能力，从而减少了页开发人员编写代码的数量，它还为开发人员提供了清晰、有序地构造页面的能力，以及可使开发工具真正做到所见即所得的功能。本部分的快速入门提供对某些基本https://www.doczj.com/doc/a89822401.html, 页功能的高级代码演练，后面部分的快速入门将深入介绍更具体的细节。
https://www.doczj.com/doc/a89822401.html, 页是采用.aspx 文件扩展名的文本文件。页由代码和HTML组成，并在服务器上动态编译和执行以呈现给发出请求的客户端浏览器。它们放在IIS 服务器上的虚拟目录中。当浏览器客户端请求.aspx 资源时，https://www.doczj.com/doc/a89822401.html, 运行库会对目标文件进行分析并将其编译为.NET Framework 类。然后，可以使用此类动态处理传入的请求。
只需获取现有HTML 文件并将该文件的文件扩展名更改为.aspx，就可以创建一个https://www.doczj.com/doc/a89822401.html, 页。例如，下面的示例演示了一个简单HTML 页，它收集用户名和类别首选项，然后在单击某一按钮时执行窗体回发，发送至发起请求的页。
重要事项：注意在单击“Lookup”（查找）按钮时，不会发生任何操作。这是因为.aspx 文件只包含静态HTML（不包含动态内容）。因此，相同的HTML 在每次发送到页时都会被发送回客户端，这会导致在请求之间窗体字段（文本框和下拉列表）的内容丢失。
https://www.doczj.com/doc/a89822401.html, 提供了与现有ASP 页的语法兼容性。这包括对<% %>代码呈现块的支持，这些块可以与.aspx 文件中的HTML 内容混用。在呈现页时，这些代码块以从上至下的方式执行。
重要事项：与ASP 不同，上述<% %>块中使用的代码实际上是使用脚本引擎编译的，而不是解释。这可以提高运行时执行性能。
https://www.doczj.com/doc/a89822401.html, 页开发人员可利用<% %>代码块动态修改HTML 输出，就好像目前可使用ASP 进行修改一样。例如，下面的示例演示如何使用<% %>代码块解
释从客户端发回的请求。
重要事项：尽管<% %>代码块提供了一种对从https://www.doczj.com/doc/a89822401.html, 页返回的文本输出进行自定义操作的强大方法，但这些代码块未提供一种清晰的HTML 编程模型。正如上述示例所阐述的那样，只使用<% %>代码块的开发人员必须自定义管理往返过程之间的页状态并自定义解释发送的值。
除了代码和标记之外，https://www.doczj.com/doc/a89822401.html, 页还可以包含服务器控件，这些控件是可编程的服务器端对象，通常表示页中的用户界面元素，如文本框或图像等。服务器控件参与页的执行，并生成它们自己的标记呈现给客户端。服务器控件的主要优点在于它们使开发人员可以从简单的构造块组件获取复杂的呈现和行为，从而大幅度减少了生成动态网页所需的代码量。服务器控件的另一个优点在于可以很容易地自定义其呈现或行为。服务器控件公开可以声明方式（通过标记）或编程方式（通过代码）设置的属性。服务器控件（和页本身）还公开了一些事件，开发人员可以处理这些事件以在页执行期间执行特定的操作或响应将页发回服务器
的客户端操作（“回发”）。此外，服务器控件还简化了在往返于服务器的过程中保留状态的问题，自动在连续回发之间保留其值。
服务器控件在.aspx 文件中是使用自定义标记或包含runat="server" 属性值
的内部HTML 标记声明的。内部HTML 标记由System.Web.UI.HtmlControls 命名空间中的某个控件处理。未显式映射到这些控件之一的任何标记都将被指定为System.Web.UI.HtmlControls.HtmlGenericControl 类型。
下面的示例使用以下四个服务器控件：