Redirection des utilisateurs de la page d'édition vers la page d'appel

Question

Je travaille sur une application Web de gestion de projet.L'utilisateur dispose de différentes manières pour afficher une liste de tâches.Lorsqu'ils consultent une page de liste, ils cliquent sur la tâche et sont redirigés vers la page d'édition de la tâche.

Puisqu'ils viennent de diverses manières, je suis simplement curieux de savoir meilleur le moyen de réorienter l'utilisateur retourne à la page d'appel.J'ai quelques idées, mais j'aimerais avoir l'avis d'autres développeurs.

Souhaitez-vous stocker le appel URL en session ?comme cookie ?J'aime le concept d'utilisation d'un objet poignée la réorientation.

Answer 1

Je stockerais l'URL de référence en utilisant le État d'affichage.Stocker cela en dehors de la portée de la page (c'est-à-diredans l'état de session ou dans le cookie) peut causer des problèmes si plusieurs fenêtres de navigateur sont ouvertes.

L'exemple ci-dessous valide que la page a été appelée en interne (c'est-à-direnon demandé directement) et revient à la page de référence une fois que l'utilisateur a soumis sa réponse.

public partial class _Default : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        if (Request.UrlReferrer == null)
        {
            //Handle the case where the page is requested directly
            throw new Exception("This page has been called without a referring page");
        }

        if (!IsPostBack)
        {   
            ReturnUrl = Request.UrlReferrer.PathAndQuery;
        }
    }

    public string ReturnUrl
    {
        get { return ViewState["returnUrl"].ToString();  }
        set { ViewState["returnUrl"] = value; }
    }

    protected void btn_Click(object sender, EventArgs e)
    {
        //Do what you need to do to save the page
        //...

        //Go back to calling page
        Response.Redirect(ReturnUrl, true);
    }
}

Answer 2

Ce message peut être étiqueté asp.net mais je pense qu'il s'agit d'un problème indépendant de la plate-forme qui dérange tous les nouveaux développeurs Web alors qu'ils recherchent une manière « propre » de le faire.

Je pense que les deux options pour y parvenir sont :

1. Un paramètre dans l'url
2. Une URL stockée dans la session

Je n'aime pas la méthode url, elle est un peu compliquée et vous devez vous rappeler d'inclure le paramètre dans chaque URL pertinente.

J'utiliserais simplement un objet avec des méthodes statiques pour cela.L'objet entourerait l'élément de session que vous utilisez pour stocker les URL de redirection.

Les méthodes seraient probablement les suivantes (toutes statiques publiques) :

• setRedirectUrl (URL de chaîne)
• doRedirect (chaîne URL par défaut)

setRedirectUrl serait appelé dans toute action produisant des liens/formulaires devant rediriger vers une URL donnée.Supposons que vous ayez une action d'affichage de projets qui génère une liste de projets, chacun avec des tâches qui peuvent être effectuées dessus (par ex.delete, edit), vous appelleriez RedirectClass.setRedirectUrl("/project/view-all") dans le code de cette action.

Supposons ensuite que l'utilisateur clique sur Supprimer, il doit être redirigé vers la page d'affichage après une action de suppression, donc dans l'action de suppression, vous appelleriez RedirectClass.setRedirectUrl("/project/view-all").Cette méthode vérifierait si la variable de redirection a été définie dans la session.Si c'est le cas, redirigez vers cette URL.Sinon, redirigez vers l'URL par défaut (la chaîne passée à la méthode setRedirectUrl).

Answer 3

Je suis d'accord avec "rmbarnes.myopenid.com" concernant ce problème comme étant indépendant de la plate-forme.

Je stockerais l'URL de la page appelante dans QueryString ou dans un champ caché (par exemple dans ViewState pour ASP.NET).Si vous le stockez en dehors de la portée de la page (comme une session, une variable globale - État de l'application, etc.), ce ne sera pas simplement excessif comme l'a dit Tom, mais cela vous posera des problèmes.

Quel type de problème?Problème si l’utilisateur a ouvert plusieurs onglets (fenêtres) de ce navigateur.Les onglets (ou fenêtres) d'un même navigateur partageront probablement la même session et la redirection ne sera pas celle attendue et tout ce que l'utilisateur ressentira, c'est qu'il s'agit d'un bug.

Mes 2 centimes d'euro..

Answer 4

Personnellement, je stockerais les informations de redirection requises dans un objet et les gérerais globalement.J'éviterais d'utiliser un paramètre QueryString ou similaire, car ils pourraient essayer de revenir sur une page qu'ils ne sont pas censés faire (problème de sécurité possible ?).Vous pouvez ensuite créer une méthode statique pour gérer l'objet de redirection, qui pourrait lire les informations et agir en conséquence.Cela résume votre processus de redirection dans une seule page.

Utiliser un objet signifie également que vous pouvez l'étendre ultérieurement si nécessaire (par exemple en ajoutant des messages de retour et d'autres informations).

Par exemple (il s'agit d'une ligne directrice approximative de 2 minutes BTW !) :

public partial class _Default : System.Web.UI.Page 
{

    void Redirect(string url, string messsage)
    {
        RedirectionParams paras = new RedirectionParams(url, messsage);
        RedirectionHandler(paras); // pass to some global method (or this could BE the global method)
    }
    protected void Button1_Click(object sender, EventArgs e)
    {
        Redirect("mypage.aspx", "you have been redirected");
    }
}

public class RedirectionParams
{
    private string _url;

    public string URL
    {
        get { return _url; }
        set { _url = value; }
    }

    private string _message;

    public string Message
    {
        get { return _message; }
        set { _message = value; }
    }

    public RedirectionParams(string url, string message)
    {
        this.URL = url;
        this.Message = message;
    }
}