附录 1 英文原文
Introduction to Pages and Inline Code and Share[10] The 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 ( provides syntax compatibility with existing pages), the 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 page features. Subsequent sections of the QuickStart drill down into more specific details. 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 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 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.
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.
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 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, 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 <input type="hidden"> 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, enables developers to utilize richer custom controls on their pages. For example, the following sample demonstrates how the <asp:adrotator> control can be used to dynamically display rotating ads on a page.
Each server control is capable of exposing an object model containing properties, methods, and events. 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 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 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 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 <script></script>tags in the same page containing the server controls. 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, 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.
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, 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). 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 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.
<configuration>
<system.web>
<compilation>
<codeSubDirectories>
<add directoryName="Subdirectory"/>
</codeSubDirectories>
</compilation>
</system.web>
</configuration>
Supported in 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 applications. You can register additional assemblies by registration in a Web.config file in your application.
<configuration>
<compilation>
<assemblies>
<add assembly="System.Data, Version=1.0.2411.0,
Culture=neutral,
PublicKeyToken=b77a5c561934e089"/>
</assemblies>
</compilation>
</configuration>
附录 2 中文译文
介绍以及内联代码和共享
Web 窗体页框架是一种可用于在服务器上动态生成网页的可伸
缩公共语言运行库编程模型。
作为ASP的继承和发展， 页框架消除了以前ASP中存在的缺陷。
尤其是，它提供了创建和使用可封装常用功能的可重用用户界面控件的能力，从而减少了页开发人员编写代码的数量，它还为开发人员提供了清晰、有序地构造页面的能力，以及可使开发工具真正做到所见即所得的功能。
本部分的快速入门提供对某些基本 页功能的高级代码演练，后面部分的快速入门将深入介绍更具体的细节。
页是采用.aspx 文件扩展名的文本文件。
页由代码和HTML组成，并在服务器上动态编译和执行以呈现给发出请求的客户端浏览器。
它们放在IIS 服务器上的虚拟目录中。
当浏览器客户端请求.aspx 资源时， 运行库会对目标文件进行分析并将其编译为.NET Framework 类。
然后，可以使用此类动态处理传入的请求。
只需获取现有HTML 文件并将该文件的文件扩展名更改为.aspx，就可以创建一个 页。
例如，下面的示例演示了一个简单HTML 页，它收集用户名和类别首选项，然后在单击某一按钮时执行窗体回发，发送至发起请求的页。
重要事项：注意在单击“Lookup”（查找）按钮时，不会发生任何操作。
这是因为.aspx 文件只包含静态HTML（不包含动态内容）。
因此，相同的HTML 在每次发送到页时都会被发送回客户端，这会导致在请求之间窗体字段（文本框和下拉列表）的内容丢失。
提供了与现有ASP 页的语法兼容性。
这包括对<% %>代码呈现块的支持，这些块可以与.aspx 文件中的HTML 内容混用。
在呈现页时，这些代码块以从上至下的方式执行。
重要事项：与ASP 不同，上述<% %>块中使用的代码实际上是使用脚本引擎编译的，而不是解释。
这可以提高运行时执行性能。
页开发人员可利用<% %>代码块动态修改HTML 输出，就好像目前可使用ASP 进行修改一样。
例如，下面的示例演示如何使用<% %>代码块解
释从客户端发回的请求。
重要事项：尽管<% %>代码块提供了一种对从 页返回的文本输出进行自定义操作的强大方法，但这些代码块未提供一种清晰的HTML 编程模型。
正如上述示例所阐述的那样，只使用<% %>代码块的开发人员必须自定义管理往返过程之间的页状态并自定义解释发送的值。
除了代码和标记之外， 页还可以包含服务器控件，这些控件是可编程的服务器端对象，通常表示页中的用户界面元素，如文本框或图像等。
服务器控件参与页的执行，并生成它们自己的标记呈现给客户端。
服务器控件的主要优点在于它们使开发人员可以从简单的构造块组件获取复杂的呈现和行为，从而大幅度减少了生成动态网页所需的代码量。
服务器控件的另一个优点在于可以很容易地自定义其呈现或行为。
服务器控件公开可以声明方式（通过标记）或编程方式（通过代码）设置的属性。
服务器控件（和页本身）还公开了一些事件，开发人员可以处理这些事件以在页执行期间执行特定的操作或响应将页发回服务器
的客户端操作（“回发”）。
此外，服务器控件还简化了在往返于服务器的过程中保留状态的问题，自动在连续回发之间保留其值。
服务器控件在.aspx 文件中是使用自定义标记或包含runat="server" 属性值
的内部HTML 标记声明的。
内部HTML 标记由System.Web.UI.HtmlControls 命名空间中的某个控件处理。
未显式映射到这些控件之一的任何标记都将被指定为System.Web.UI.HtmlControls.HtmlGenericControl 类型。
下面的示例使用以下四个服务器控件：<form runat=server>、<asp:textbox runat=server>、<asp:dropdownlist runat=server>和<asp:button runat=server>。
在运行时，这些服务器控件将自动生成HTML 内容。
重要事项：注意，在到服务器的往返过程之间，这些服务器控件自动保留客户端输入的任何值。
此控件状态不存储在服务器上（而是存储在往返于请求之间的<input type="hidden">窗体字段中）。
另外，还须注意不需要客户端脚本。
除支持标准HTML 输入控件之外， 还使开发人员能够在他们的页上利用更丰富的自定义控件。
例如，下面的示例演示如何使用<asp:adrotator>控件在页上动态显示循环广告。
重要事项：所有内置服务器控件的详细列表可在本快速入门的“控件参考” 部
分中找到。
每个 服务器控件都可以公开包含属性、方法和事件的对象模型。
开发人员可以使用此对象模型清晰地修改页以及与页进行交互。
下面的示例演示 页开发人员可如何处理<asp:button runat=server>
控件中的OnClick 事件以操作<asp:label runat=server>控件的Text 属性。
提供了可以组织页中代码的两种方法。
下面的代码示例演示一个包含以下三个服务器控件的简单 页：TextBox、Button 和Label。
最初，这些控件只呈现其HTML 窗体等效项。
但是，当客户端在TextBox 中键入了一个值并单击了Button 后，该页会回发到服务器，然后该页使用页中的代码处理此单击事件，动态地更新Label 控件的Text 属性。
然后，该页将重新呈现以反映更新后的文本。
此简单示例演示了服务器控件模型内在的基本机制，该模型使 成为最容易学习和掌握的Web 编程模型之一。
调用此类型的页编程“代码内联”，如果您要在一个文件中维护您的代码和表示逻辑，则该方法十分有用。
但 还支持另一种分解代码和表示内容的方法，该方法称为“代码隐藏”模型。
在使用代码隐藏时，处理事件的代码所在的文件与包含服务器控件和标记的页在物理上分开。
在您需要分别维护代码和内容（如有多个人员参与创建应用程序工作）时，这种将代码和内容清楚区分的方法十分有用。
在团队项目中，设计人员通常负责应用程序的用户界面部分的工作，而开发人员则负责行为或代码部分。
代码隐藏模型非常适用于此类环境。
2.0 为代码隐藏页引入了一个改进的运行库，该库可简化页和代码之间的连接。
在这一新的代码隐藏模型中，页被声明为分部类，这使得页和代码文件可在运行时编译为一个类。
通过在Inherits 属性中指定类名，页代码使用<%@ Page %>指令的CodeFile 属性来引用代码隐藏文件。
请注意，代码隐藏类的成员必须是公共或受保护的成员（不能为私有成员）。
与以前版本相比，这种简化的代码隐藏模型的好处在于无需维护代码隐藏类中服务器控件变量的各个不同的声明。
使用分部类（2.0 中的新增功能）可在代码隐藏文件中直接访问ASPX 页的服务器控件ID。
这极大地简化了代码隐藏页的维护工作。
尽管可以将代码放在站点的每个页上（使用上一节中所述的内联或代码隐藏分离模型），但有时您将希望在站点中的多个页之间共享代码。
将这些代码复制到需要它们的每个页上，这种做法既低效又使代码难以维护。
幸运的是， 提供了几种简单的方法，使应用程序中的所有页都可以访问代码。
与页可在运行时动态编译一样，任意代码文件（例如，.cs 或.vb 文件）也可以在运行时动态编译。
2.0 引入了App_Code 目录，该目录可以包含一些独立文件，这些文件包含要在应用程序中的多个页之间共享的代码。
与 1.x 不同（1.x 需要将这些文件预编译到Bin 目录），App_Code 目录中的所有代码文件都将在运行时动态编译，然后提供给应用程序。
可以在
App_Code 目录下放置多种语言的文件，前提是将这些文件划分到各子目录中（在Web.config 中用特定语言注册这些子目录）。
下面的示例演示如何使用App_Code 目录包含一个从页调用的类文件。
默认情况下，App_Code 目录只能包含同一种语言的文件。
但可以将
App_Code 目录划分为若干子目录（每个子目录包含同一语言的文件）以便可以在App_Code 目录下包含多种语言。
为此，需要在应用程序的Web.config 文件中注册每个子目录。
<configuration>
<system.web>
<compilation>
<codeSubDirectories>
<add directoryName="Subdirectory"/>
</codeSubDirectories>
</compilation>
</system.web>
</configuration>
在 版本中支持Bin 目录，该目录类似于Code 目录，不同的是它可以包含预编译的程序集。
如果需要使用其他人编写的代码，则此目录就很有用了，您不用访问源代码（VB 或C# 文件）就可以得到编译后的DLL。
主要在你的程序中将该DLL作为引用添加到你的工程。
默认情况下，Bin 目录中的所有
程序集都自动加载到应用程序中，然后可供各页访问。
您可能需要使用页最上方的@Import 指令从Bin 目录的程序集中导入特定的命名空间。
<@ Import Namespace="MyCustomNamespace" >
.NET Framework 2.0 提供了表示Framework 的各个部件的大量类库程序集。
这些程序集存储在全局程序集缓存中，该缓存是程序集的版本化存储库，可供计算机上的所有应用程序使用。
Framework 中的多个程序集都可自动提供给 应用程序。
通过在应用程序的Web.config 文件中注册，并且可以注
册更多的程序集。
<configuration>
<compilation>
<assemblies>
<add assembly="System.Data, Version=1.0.2411.0,
Culture=neutral,
PublicKeyToken=b77a5c561934e089"/>
</assemblies>
</compilation>
</configuration>。
