2008-08-31 19 views
7

Estoy trabajando en una aplicación web de administración de proyectos. El usuario tiene una variedad de formas de mostrar una lista de tareas. Al visualizar una página de lista, hacen clic en la tarea y se redirigen a la página de edición de la tarea.Redirigir a los usuarios de la página de edición a la página de llamadas

Ya que provienen de una variedad de maneras, estoy curioso en cuanto a la forma en mejor a redirigir al usuario a la página de llamada. Tengo algunas ideas, pero me gustaría obtener comentarios de otros desarrolladores.

¿Almacenarías el llamando al url en sesión? como una galleta? Me gusta el concepto de utilizar un objeto manejar la redirección.

Respuesta

5

Me almacenar la URL de referencia utilizando el ViewState. Almacenar esto fuera del alcance de la página (es decir, en el estado de la sesión o en la cookie) puede causar problemas si hay más de una ventana del navegador abierta.

El ejemplo siguiente valida que la página se llamó internamente (es decir, no se solicitó directamente) y rebota en la página de referencia una vez que el usuario envía su respuesta.

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); 
    } 
} 
1

Yo personalmente almacenaría la información de redirección requerida en un objeto y manejaría globalmente. Evitaría usar un param de QueryString o similar, ya que podrían tratar de rebotar de vuelta a una página que no deberían (¿posible problema de seguridad?). A continuación, podría crear un método estático para manejar el objeto de redirección, que podría leer la información y actuar en consecuencia. Esto encapsula su proceso de redireccionamiento dentro de una página.

El uso de un objeto también significa que puede ampliarlo más adelante si es necesario (como agregar mensajes de devolución y otra información).

Por ejemplo (esto es una guía aproximada 2 minutos por cierto!):

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; 
    } 
} 
1

Este mensaje Mi ser marcados como asp.net pero creo que es una cuestión independiente de la plataforma que duele todos los nuevos desarrolladores web a medida que buscan una forma 'limpia' para hacer esto.

creo que las dos opciones para lograr esto son:

  1. Un parámetro en la URL
  2. Un URL almacenada en la sesión

no me gusta el método de URL, se es un poco desordenado, y debe recordar incluir el parámetro en cada URL relevante.

Solo usaría un objeto con métodos estáticos para esto. El objeto se ajustaría al elemento de la sesión que utiliza para almacenar direcciones URL de redireccionamiento.

Los métodos probablemente serían los siguientes (todas public static):

  • setRedirectUrl (String url)
  • doRedirect (cadena defaultURL)

setRedirectUrl sería llamado en cualquier acción que produce enlaces/formularios que necesitan redirigir a una URL determinada. Así que supongamos que tiene una acción de vista de proyectos que genera una lista de proyectos, cada uno con tareas que se pueden realizar en ellos (por ejemplo, eliminar, editar) que llamaría a RedirectClass.setRedirectUrl ("/ project/view-all") en el código para esta acción.

Entonces digamos que el usuario hace clic en eliminar, necesitan ser redirigidos a la página de vista después de una acción de eliminación, por lo que en la acción de eliminar llamaría a RedirectClass.setRedirectUrl ("/ project/view-all"). Este método vería si la variable de redirección se configuró en la sesión. Si es así, redirija a esa URL. De lo contrario, redirija a la URL predeterminada (la cadena pasó al método setRedirectUrl).

1

Estoy de acuerdo con "rmbarnes.myopenid.com" con respecto a este problema como plataforma independiente.

Guardaría la URL de la página llamante en QueryString o en un campo oculto (por ejemplo, en ViewState para ASP.NET). Si lo va a almacenar fuera del alcance de la página (como la Sesión, la variable global, el Estado de la aplicación, etc.), no será exagerado como dijo Tom, pero le traerá problemas.

¿Qué tipo de problema? Problemas si el usuario tiene abiertas más de una pestaña (ventana) de ese navegador. Las pestañas (o ventanas) del mismo navegador probablemente compartan la misma sesión y la redirección no será la esperada y todo lo que el usuario sentirá es que se trata de un error.

Mis 2 céntimos de euro ..

Cuestiones relacionadas