This is an article that I wrote on 8^th November 2004, which I later removed from my old website.  Fortunately, it had been copied verbatim and translated into VB.NET (although neither of them acknowledge that it's my article), so I thought I'd add it to my new blog (with some minor code adjustments).

Introduction

A common problem that Web Application Developers encounter is how to stop the user from refreshing the page. This is a problem if the previous request to the server was a PostBack, which, for example, inserted the WebForm’s data into a database. The result: duplicate rows in the database. The answer to this problem is that you can’t stop the user from refreshing the page, however there is a way to determine if this event has occurred.

In his article “Build Your ASP.NET Pages on a Richer Bedrock” [no longer available] Dino Esposito outlined a mechanism to detect a page refresh. This method is cumbersome and more complicated than necessary, although the fundamental idea is sound and forms the basis of this solution. Dino’s mechanism uses a counter stored on the page and a session variable to store the previous request’s counter on the server, if the two match then we have a page refresh.

A simpler method

Keeping the whole process within a base Page class ensures that the mechanism is completely encapsulated (and simple to implement) and if we use ViewState we eliminate the need to use an additional hidden field. Also, as we simply want to test if the two storage devices contain the same value, we can use two boolean variables, which further simplifies the process.

The last decision to make is where, in the Page’s lifecycle, should the process take place. As we are using ViewState it would seem logical to perform the operation in the LoadViewState and SaveViewState methods. Using these two methods, and not the OnLoad method, has further benefits in that it eliminates potential problems with derived classes implementing Page_Load.

How the process works

The LoadViewState method, which is part of the Page’s initialisation phase, is only invoked during PostBack and therefore SaveViewState is the only method, of the two ViewState related methods, to be called when the page is first requested.

protected override object SaveViewState()
{
    SessionState = RefreshState;
    var allStates = new object[2];
    allStates[0] = base.SaveViewState();
    allStates[1] = !RefreshState;
    return allStates;
}

Figure 1

Note: RefreshState (which on initial page request is defaulted to false and on subsequent PostBack requests is the value of ViewState) is assigned to the SessionState item and the negated RefreshState is saved to the new ViewState.

Once a PostBack event takes place the LoadViewState method is called.

protected override void LoadViewState(object savedState)
{
    var allStates = (object[]) savedState;
    base.LoadViewState(allStates[0]);
    RefreshState = (bool) allStates[1];
    IsRefresh = RefreshState == SessionState;
}

Figure 2

Note: The RefreshState is retrieved from ViewState and compared with the value in the SessionState. The result is stored in IsRefresh Property.

The listing below shows the entire class definition:

namespace StevenBey.Web.UI
{
    public class Page : System.Web.UI.Page
    {
        protected override void LoadViewState(object savedState)
        {
            var = (object[]) savedState;
            base.LoadViewState(allStates[0]);
            RefreshState = (bool) allStates[1];
            IsRefresh = RefreshState == SessionState;
        }
        protected override object SaveViewState()
        {
            SessionState = RefreshState;
            var = new object[2];
            allStates[0] = base.SaveViewState();
            allStates[1] = !RefreshState;
            return allStates;
        }
        public bool IsRefresh { get; private set; }
        bool RefreshState { get; set; }
        bool SessionState
        {
            get { return (bool) Session["__ISREFRESH"]; }
            set { Session["__ISREFRESH"] = value; }
        }
    }
}

Figure 3

Testing the process

<%@ Page Inherits="StevenBey.Web.UI.Page" %>
<html>
    <head>
        <title>Detecting Page Refresh</title>
    </head>
    <body>
        IsRefresh = <%= IsRefresh %>
        <form runat="server">
            <asp:Button runat="server" Text="Submit" />
        </form>
    </body>
</html>

Figure 4

Clicking on the button invokes a PostBack, however the value of IsRefresh doesn’t change until you click on the browser’s Refresh button or press F5 on the keyboard (and then click “Retry”). Clicking on the button once again resets the value of IsRefresh to false.

Conclusion

In this article I have demonstrated a simplified method of detecting a page refresh event.

Introduction

Recently, I started working on a large eCommerce website, implemented in ASP.NET MVC 3. I soon found that many of the forms in the site contained code similar to Figure 1, which I took an instant dislike to. The reason I dislike it is that “Action” doesn’t relate to anything (i.e. it isn’t an actual action name) and causes the URL to change when the form is submitted, so a URL like “/Blog/AddPost” will suddenly become “/Blog/Action”. Another side-effect is that the destination action method must specify explicitly the view name. I then discovered that it was to enable multiple submit buttons by using an implementation of the ActionNameSelectorAttribute class (Figure 2).

@using(Html.BeginForm("Action", null))
{
    <button name="Save">Save</button>
    <button name="Publish">Publish</button>
}

Figure 1

public class SubmitButtonNameActionNameSelector : ActionNameSelectorAttribute
{
    public override bool IsValidName(
        ControllerContext controllerContext,
        string actionName,
        MethodInfo methodInfo)
    {
        if(actionName.Equals(methodInfo.Name, StringComparison.InvariantCultureIgnoreCase))
            return true;

        if(!actionName.Equals("Action", StringComparison.InvariantCultureIgnoreCase))
            return false;

        var request = controllerContext.RequestContext.HttpContext.Request;
        return request[methodInfo.Name] != null;
    }
}

Figure 2

public class BlogController : Controller
{
    [SubmitButtonNameActionNameSelector]
    public ActionResult Save()
    {
        //...
    }
    [SubmitButtonNameActionNameSelector]
    public ActionResult Publish()
    {
        //...
    }
}

Figure 3

Previous technique

In other projects I’ve used a popular technique of binding the button’s name to a parameter name in the action method and then determining the button’s value, in order to branch to a different method. There are downsides to this approach but the main thing I dislike about it is that it’s quite messy. The ActionNameSelectorAttribute implementation allows for a cleaner separation of behaviour for each button.

Solving the problem

To circumvent the problems I have mentioned, I decided to use a variation of the SubmitButtonNameActionNameSelector implementation (Figure 4).

public class FormActionAttribute : ActionNameSelectorAttribute
{
    public override bool IsValidName(
        ControllerContext controllerContext,
        string actionName,
        MethodInfo methodInfo)
    {
        return controllerContext.HttpContext.Request[Prefix + methodInfo.Name] != null
            && !controllerContext.IsChildAction;
    }

    public string Prefix = "Action::";
}

Figure 4

public class BlogController : Controller
{
    [HttpPost, FormAction]
    public ActionResult Save()
    {
        //...
    }
    [HttpPost, FormAction(Prefix = "Action_")]
    public ActionResult Publish()
    {
        //...
    }
}

Figure 5

@using(Html.BeginForm())
{
    <button name="Action::Save">Save</button>
    <button name="Action_Publish">Publish</button>
}

Figure 6

Conclusion

By prefixing the button’s name there is no need to have “Action” as the form’s action (Figure 6), which means that the URL stays the same and there is no need to explicitly specify the view name.