Rafraîchissement de la page Vs IsPostBack

Question

J'ai une page d'index qui renvoie les utilisateurs vers une page de modification des produits dans des onglets de navigateur distincts.

Pour chaque produit édité, l'index réécrit la Session["ProductID"].

La page d'édition comporte ensuite le code suivant afin de disposer d'un identifiant unique pour cet onglet et ce produit :

if (!IsPostBack) //first time page load
{
    Random R = new Random(DateTime.Now.Millisecond + DateTime.Now.Second * 1000 + DateTime.Now.Minute * 60000 + DateTime.Now.Minute * 3600000);
    PageID.Value = R.Next().ToString();

    Session[PageID.Value + "ProductID"] = Session["ProductID"];
}

Cela fonctionne, et lorsque le même utilisateur ouvre plusieurs onglets, je ne fais référence qu'à la Session[PageID.Value + "ProductID"] dans mon code afin d'avoir toujours le bon ID. (Je travaille dans un environnement de confiance, c'est pour un intranet, donc je ne suis pas trop gêné par le niveau de sécurité).

Le problème se produit si l'utilisateur rafraîchit la page en appuyant sur la touche F5. À ce moment-là, la Session[PageID.Value + "ProductID"] reçoit la Session["ProductID"] du dernier produit qu'il a ouvert.

Par exemple :

L'utilisateur 1 ouvre le produit 1 dans l'onglet 1

L'utilisateur 1 ouvre le produit 2 dans l'onglet 2

Lorsqu'ils utilisent l'outil normalement, tout fonctionne bien. Cependant, si :

L'utilisateur 1 sur la page du produit 1 appuie sur le bouton de rafraîchissement (F5), la page du produit 1 devient la page du produit 2.

Existe-t-il un moyen de détecter un rafraîchissement de page à partir d'un "premier chargement/redirection à partir d'une autre page" afin de pouvoir dire à ma page de ne pas mettre à jour ma Session[PageID.Value + "ProductID"] ?

Answer 1

Personnellement, j'opterais pour les paramètres URL. Par exemple, passez les ID des produits comme paramètres d'URL.

Si vous avez besoin des pages sans paramètres, vous pouvez par exemple

1. Passer le paramètre à la page.
2. La page se recharge si le paramètre est présent et supprime le paramètre.

De cette façon, vous pourriez distinguer le premier appel (=paramètre présent) du deuxième+ appel (paramètre non présent).

Answer 2

Vous voudrez peut-être jeter un coup d'œil à este . Je pense que c'est proche de ce que vous recherchez.

Answer 3

J'ai résolu un problème très similaire en stockant deux versions d'un paramètre d'identification d'état : une dans la session et une autre dans le ViewState ou l'URL (QueryString).

Si vous comparez les deux valeurs lors du chargement de la page, vous saurez si la variable de session a changé depuis le premier chargement de la page. Cela devrait répondre à vos besoins.

EDIT : Esquisse du code (attention - je n'ai pas vu le code réel depuis que je l'ai écrit il y a 3 ans) :

protected string currentProductID
{
    get
    {
        return Request.QueryString["ProductID"];
        //or: 
        //return (string)ViewState["ProductID"];
        //or:
        //return HiddenField1.Value;
    }
    set
    {
        Response.Redirect(ResolveUrl("~/MyPage.aspx?ProductID=" + value));
        //or:
        //ViewState.Add("ProductID", value);
        //or: 
        //HiddenField1.Value = value;
    }
}

protected void Page_Load(object sender, EventArgs e)
{
    //If the problem only occurs when not posting back, wrap the below in
    // an if(!IsPostBack) block. My past issue occurred on both postbacks
    // and page refreshes.

    //Note: I'm assuming Session["ProductID"] should never be null.

    if (currentProductID == null)
    {
        //Loading page for the first time.
        currentProductID = (string)Session["ProductID"];
    }
    else if (currentProductID != Session["ProductID"])
    {
        //ProductID has changed since the page was first loaded, so react accordingly. 
        //You can use the original ProductID from the first load, or reset it to match the one in the Session.
        //If you use the earlier one, you may or may not want to reset the one in Session to match.
    }
}

Dans le code ci-dessus, notez que les modifications apportées au ViewState (y compris la valeur d'un contrôle caché) ne prendront effet que lors du prochain PostBack. Lors d'un rafraîchissement, elles reviendront à leur valeur la plus récente. Dans mon cas, c'est ce que je voulais, mais il semble que cela ne soit pas tout à fait adapté à votre situation. Néanmoins, cette information pourrait vous être utile, en fonction de la façon dont vous mettez en œuvre ce système.

J'ai omis de parler de la comparaison entre currentProductID a Session[PageID.Value + "ProductID"] J'ai déjà posté beaucoup de code et je ne connais pas les détails de ce que vous essayez de faire. Mais il existe plusieurs façons d'utiliser Session, ViewState et QueryString pour glaner des informations sur l'état et l'historique de la page.

J'espère que cela vous donnera une idée générale. Faites-moi savoir si cela ne suffit pas à vous faire avancer.