附录 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 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
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
