ASP.NET极限：页面导航 (翻译)

Rob Howard

在我的小时候，我每年都会花几周的时间呆在我的大家庭里。作为一个年幼的美国小男孩我当时非常着迷荷兰电力火车，一些在我的家乡－－德克萨斯州达拉斯所没有见到过的事情。我的堂兄招待我乘坐他们的小船去看经过的火车。坐在靠近车轨的水上可以听到渐近的火车，像是轻轻的口哨穿过铁轨，直到火车呼叫而过时奏出一个缓慢的高潮。在考虑ASP.NET 2.0时使我不由想起了这个。ASP.NET 2.0已经十分接近而且我们大部分都在热切期望它的发布能早点到来，我们甚至听到了发布继续越来越响的“呜”声。届时我们编写软件的方式将会改变，再一次。

微软 ASP.NET 2.0的目标是提供开发者的效能50％。然而，实际的效能提升似乎超过了预期。新的personalization, membership和角色管理特性拿掉了开发者的负担，而其他的特性，像数据绑定，也被简化了。例如，我们熟悉并依然被支持的语法：

<%# DataBinder.Eval (Container.DataItem, "FirstName") %>
 

在ASP.NET 2.0 却可以简化为:

<%# Eval("FirstName") %>
 

不仅有大量的另人印象深刻的新特性，还有大量的极具意义的服务器控件。由于服务器控件像<ASP:login>控件对membership的整合和新的data source和数据控件服务器控件，ASP.NET编程模型将在ASP.NET 2.0中变得更加强大。

在ASP.NET 2.0中System.Web类库的数量几乎翻倍－－覆盖太多甚至需要杂志专栏连载。为了真正理解这些改变的程度，您需要一本新的ASP.NET 2.0的书。我计划在这撰写一些专栏来突出一些比较重要的ASP.NET 2.0的新特性。本月刊我将重点放在导航和页面流程，以众人寻求的特性－－提交给其它页面能力作为开始。

跨页投递

我从迁移到ASP.NET开发者们那里听到抱怨最多的是页面的回发模型，ASP.NET页面可以拥有单一的<form>并且只能HTTP回发给自己，这样所有的处理逻辑都将运行在这个页面里。

许多开发者，特别是那些熟悉ASP，喜欢控制<form>元素的，会了解ASP中可以指示<form>将自己的内容数据提交到何处和如何发送（HTTP Post 或 HTTP Get），以及同一页面上<form>的数量。但与ASP相比，ASP.NET中仅允许页面只有一个<form runat=server>，并且只能回发给自己。这点可能令人十分懊恼，下面是ASP.NET2.0中发送给其他页面的示例：

<%@ Page MasterPageFile="~/Site.master" Language="C#"
    CodeFile="Source.aspx.cs"
    Inherits="Source" %>

<ASP:Content ID="MainContent"
        ContentPlaceHolderID="Main" Runat="server">
    Enter your name:
    <ASP:TextBox ID="NameBox" Runat="server"></ASP:TextBox>
    <ASP:Button ID="Button1" Runat="server" Text="Submit" />
</ASP:Content>

Master Pages用来控制页面布局，带有一个<ASP:content>块，有一些服务器控件来接受用户输入。

如果打算将内容传递到另一个页面，可以采用类似下面的服务器代码：

Response.Redirect("Target.aspx?Name= " +
    HttpUtility.UrlEncode(NameBox.Text));

这种技术的问题是当用户点击按钮提交后，服务器接受请求并发送一个响应令浏览器转向Taget.aspx，这样简单的问题却做了大量的工作！

能不能简化工作呢？在ASP.NET 2.0中答案是肯定的。接下来演示改进后的代码：

<%@ Page MasterPageFile="~/Site.master" Language="C#"
    CodeFile="Source.aspx.cs"
    Inherits="Source" %>

<ASP:Content ID="MainContent"
        ContentPlaceHolderID="Main" Runat="server">
    Enter your name:
    <ASP:TextBox ID="NameBox" Runat="server"></ASP:TextBox>
    <ASP:Button ID="Button1" Runat="server" Text="Submit"
        PostBackUrl="~/Target.aspx" />
</ASP:Content>

注意<ASP:Button>中的PostBackUrl属性，这个属性会通知按钮不再执行默认的回发而是直接提交数据到Target.aspx.

您可能想知道这是如何运作的，尤其您熟悉ASP.NET的ViewState对象时。不过那超出了本文的范围，当跨页投递特性被使用时页面会新增一个隐藏域：

<input type="hidden" name="__PREVIOUSPAGE" id="__PREVIOUSPAGE"
    value="p1-dFHlCpgH2alr1vkr3G21UIR7jOuzn074led6lbGf1KQ47_F25GwG0" />

有点像控件树所生成的视图状态，但它是给跨页投递验证此页的视图状态的碎片。您知道，当一个页面被跨页投递给另一个页面后，接受页要可以访问投递页的实例。本例中意味着Target.ASP可以访问Source.aspx的详细信息。事实上，更有效的方法是通过强类型管理器访问Source.aspx到Target.aspx的API。为了访问投递页（上个页面），ASP.NET2.0特别为跨页投递提供一个页面属性：PreviousPage。

PreviousPage返回投递页的实例，还有一个属性是用来检查是否是跨页投递：IsCrossPagePostBack。这个属性类似现有的IsPostBack但是只有跨页投递发生时返回true。

PreviousPage属性可以有不同的行为，默认只简单将上个页面的实例作为Page类型返回，但是，通过使用一个新的指令您可以让PreviousPage属性返回一个强类型实例，来访问页面的public成员。例如，将下面的代码添加到Target.aspx上：

<%@ PreviousPageType VirtualPath="~/Source.aspx" %>

现在可以在Target.aspx上使用PreviousPage属性来访问Source.aspx的数据了。然而，为了访问服务器控件，像Source.aspx上的NameBox，您还需要编写以下代码：

TextBox nameBox = PreviousPage.FindControl("NameBox") as TextBox;

换句话说，您必须使用FindControl来访问控件树。为什么呢?服务器控件默认作为受保护成员变量，为了真正地简单访问上个页面的元素，您需要将Source.aspx上的属性或方法显露为public，然后下面的代码才能工作： TextBox nameBox = PreviousPage.NameBox;

[1] [2]  下一页