asp.net - route - Redirigir a los usuarios de la página de edición a la página de llamada
asp route tag helper (4)
Estoy trabajando en una aplicación web de gestió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.
Dado que provienen de varias maneras, solo tengo curiosidad sobre la mejor manera de redirigir al usuario a la página de llamadas. Tengo algunas ideas, pero me gustaría obtener comentarios de otros desarrolladores.
¿Almacenarías la url de llamada en sesión? como una galleta? Me gusta el concepto de usar un objeto para manejar la redirección.
Almacenaba la URL de referencia usando ViewState . Almacenar esto fuera del alcance de la página (es decir, en el estado de la sesión o la cookie) puede causar problemas si hay más de una ventana del navegador abierta.
El siguiente ejemplo 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);
}
}
Este mensaje puede ser etiquetado asp.net pero creo que es un problema independiente de la plataforma que duele a todos los nuevos desarrolladores web mientras buscan una forma ''limpia'' de hacerlo.
Creo que las dos opciones para lograr esto son:
- Un param en la url
- Una url almacenada en la sesión
No me gusta el método de URL, es un poco complicado, 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 (todos públicos estáticos):
- setRedirectUrl (cadena URL)
- doRedirect (string defaultURL)
Se llamará a setRedirectUrl en cualquier acción que produzca enlaces / formularios que necesiten 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 visualización después de una acción de eliminación, por lo que en la acción de eliminación llamarías 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).
Estoy de acuerdo con "rmbarnes.myopenid.com" con respecto a este tema como independiente de la plataforma.
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.
¿Que 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 ...
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.
Usar un objeto también significa que luego puede ampliarlo si es necesario (como agregar mensajes de devolución y otra información).
Por ejemplo (¡esta es una guía aproximada de 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;
}
}