June 09, 2004
|
Cross-page posting in Whidbey, Part 2
|
19713 hit(s)
I have a couple more details on ASP.NET Whidbey cross-page posting to add to the original entry. What I've covered is how to specify a cross-page post (set the PostBackUrl property of a button) and how on the target page to get the value(s) of control(s) from the source page.
For the latter, you use FindControl. A point I didn't make last time was that FindControl is scoped to a naming container. You can do this:PreviousPage.FindControl(controlId) to find a control on the page, but if the control you're looking for is in a template someplace, you'll need to first use FindControl to get a reference to the template's owner and then a second FindControl on the result to get the actual control. Could be tedious.
Another way to get access to the source page, as I had alluded to and Colt nailed, is to configure strong access to the source page. To review, in the target page, the PreviousPage property gets a reference to the source page, but it's typed simply to Page. However, in the target page you can include a PreviousPageType directive like this:<%@ PreviousPageType VirtualPath="~/SourcePage.aspx" %> (Alternatively, instead of VirtualPath you can specify a Type attribute and specify the actual type you want.) Including this directive causes the target page to automatically cast the PreviousPage property to the type of the page you specify.
Great, but what does it get you? Well, if the source page has public properties, you can get strongly typed access to them, like this (in the target):Label1.Text = PreviousPage.City where City is a public property on the source page. Obviously, this is going to be most useful when you have built the source page with the idea in mind of doing precisely what's illustrated here. A good use, perhaps, would be to use public properties on the source page to expose the control properties you are interested in. That gives you typed access to those properties without having to invoke FindControl. Note that strongly typing the source page doesn't give you any better access to the source page controls than untyped access; controls are protected, so you just can't get to them without the FindControl rigamarole or wrapping the interesting stuff in public properties.
Public properties on the source page might as well be read-only. It's not a technical requirement, and you can even set the properties from the target page, but it's not good for anything -- any values you set aren't persisted.
I should probably note that any access to the source page whatsover is predicated on the source and target pages being in the same application. You can cross-post to any arbitrary URL, and it will work. But if the source page is in some other application, PreviousPage won't get you any reference, because there's no way to get an instance of that page.
Cross-post or postback or Server.Transfer?
You might design your pages so that SourcePage.aspx cross-posts to TargetPage.aspx, but it's always possible that TargetPage.aspx is requested on its own. You should therefore always test PreviousPage to be sure it contains the source page reference you think it does:If Not PreviousPage Is Nothing Then
' Do your PreviousPage thing ...
Else
' Not a cross-post target (this time, anyway ...)
End If In the target of a cross-posted page, normal postback semantics apply. The first time the page runs (as a result of the cross-post), IsPostBack is false. If the target page has posted to itself, IsPostBack is true, as expected, and PreviousPage is uninitialized. Coz by then it's a normal page in normal mode, so to speak.
Something not immediately obvious is that everything that applies to cross-posting also applies to Server.Transfer. This includes a page reference in PreviousPage and strong typing via the PreviousPageType directive. If you've used Server.Transfer in the past and used Context.Handler to get a reference to the source page, well, you won't have to any more in Whidbey -- just use PreviousPage as described here.
However, that does raise a slight problem, namely, when it's useful to do so, how do you know whether the current page was invoked via cross-page posting versus Server.Transfer? Anticipating this question, they added a property IsCrossPagePostBack to the Page class. In the target page, you test that property for the PreviousPage reference. Basically, if PreviousPage.IsCrossPagePostBack is true, you got to the target via a cross-post; if it's false, you got there via Server.Transfer.
And I think that's about it for cross-page posting. I don't know of anything else there might be to say, but if you think of anything, let me know, coz I'll need to put in in the docs. :-)
|
|
