One of the problems evident in many ASP.NET applications is that there is no built in way to externalize application flow information. The most common way of defining application flow is by hardcoding calls to the Response.Redirect or Server.Transfer methods within event handlers.
This approach is problematic because it requires code changes (with the attendant recompilation) if one decides to change the application screen flow (for whatever reason). A much better way, and the one that has been proven to work successfully in many MVC (Model-View-Controller
) web frameworks is to provide the means to externalize the mapping of action results to target pages.
Spring.Web adds this functionality to ASP.NET by allowing one to define result mappings within the definition of a page, and to then simply use logical result names within event handlers to control application flow.
Note that because a logical result is represented by the Result class, one can configure results just like any other Spring.NET object:
<objects>
<object id="homePageResult" type="Spring.Web.Support.Result, Spring.Web">
<property name="TargetPage" value="~/Default.aspx"/>
<property name="Mode" value="Transfer"/>
<property name="Parameters">
<dictionary>
<entry key="literal" value="My Text"/>
<entry key="name" value="${UserInfo.FullName}"/>
<entry key="host" value="${Request.UserHostName}"/>
</dictionary>
</property>
</object>
<object id="loginPageResult" type="Spring.Web.Support.Result, Spring.Web">
<property name="TargetPage" value="Login.aspx"/>
<property name="Mode" value="Redirect"/>
</object>
<object type="UserRegistration.aspx" parent="basePage">
<property name="UserManager" ref="userManager"/>
<property name="Results">
<dictionary>
<entry key="userSaved" value-ref="homePageResult"/>
<entry key="cancel" value-ref="loginPageResult"/>
</dictionary>
</property>
</object>
</objects>
The only property that you must specify for the result is TargetPage. The value of the Mode property can be either Transfer or Redirect, and defaults to Transfer if none is specified.
If one's target page requires parameters, one can define them using the Parameters dictionary property. One simply specifies either literal values or object navigation expressions for such parameter values; if one specifies an expression, this expression will be evaluated in the context of the page in which the result is being referenced... in the specific case of the above example, this means that any page that uses the homePageResult needs to expose a UserInfo property on the page class itself.
Parameters will be handled differently depending on the result mode. For redirect results, each parameter will be converted to string, URL encoded, and then finally appended to a redirect query string. On the other hand, parameters for transfer results will be added to the HttpContext.Items collection before the request is transfered to the target page. This means that transfers are more flexible because any object can be passed as a parameter between pages. They are also more efficient because they don't require a round-trip to the client and back to the server, so transfer mode is recommended as the preferred result mode (it is also the current default).
The above example shows independent result object definitions, which are useful for global results such as a home- and login- page. Result definitions that are only used by one page should be simply embedded within the definition of a page, either as inner object definitions or using a special shortcut notation for defining a result definition:
<object type="~/UI/Forms/UserRegistration.aspx" parent="basePage">
<property name="UserManager">
<ref object="userManager"/>
</property>
<property name="Results">
<dictionary>
<entry key="userSaved" value="transfer:UserRegistered.aspx?status=Registration Successful,user=${UserInfo}"/>
<entry key="cancel" value-ref="homePageResult"/>
</dictionary>
</property>
</object>
The short notation for the result must adhere to the following format:
One thing to notice is that a comma is used instead of an ampersand to separate parameters; this is done so as to avoid the need for laborious ampersand escaping within an XML object definition. The use of the ampersand character is still supported if required, but one will then have to specify it using the well known & entity reference.
Once one has defined one's results, it is very simple to use them within the event handlers of one's pages:
private void SaveUser(object sender, EventArgs e)
{
UserManager.SaveUser(UserInfo);
SetResult("userSaved");
}
public void Cancel(object sender, EventArgs e)
{
SetResult("cancel");
}
protected override void OnInit(EventArgs e)
{
InitializeComponent();
this.saveButton.Click += new EventHandler(this.SaveUser);
this.cancelButton.Click += new EventHandler(this.Cancel);
base.OnInit(e);
}
One could of course further refactror the above example and use defined constants. This would be a good thing to do in the case of a logical result name such as "home" that is likely to be referenced by many pages.
