Перенаправление пользователей от страницы редактирования назад к вызову страницы
Я написал небольшую удобную функцию для размещения JSON.
$.postJSON = function(url, data, success, args) {
args = $.extend({
url: url,
type: 'POST',
data: JSON.stringify(data),
contentType: 'application/json; charset=utf-8',
dataType: 'json',
async: true,
success: success
}, args);
return $.ajax(args);
};
$.postJSON('test/url', data, function(result) {
console.log('result', result);
});
4 ответа
Я сохранил бы относящийся URL с помощью ViewState. Хранение этой внешней стороны, объем страницы (т.е. в Состоянии сеанса или cookie) может вызвать проблемы, если больше чем одно окно браузера открыто.
Пример ниже проверяет это, страницу назвали внутренне (т.е. не требовали непосредственно), и приходит в норму к относящейся странице после того, как пользователь отправляет их ответ.
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);
}
}
Это сообщение мой быть отмеченным asp.net, но я думаю, что это - независимая от платформы проблема, которая причиняют боль все новые веб-разработчики, поскольку они ищут 'чистый' способ сделать это.
Я думаю эти две опции в достижении, это:
- Параметрический усилитель в URL
- URL сохранен на сессии
Мне не нравится метод URL, это немного грязно, и необходимо не забыть включать параметрический усилитель в каждый соответствующий URL.
Я просто использовал бы объект со статическими методами для этого. Объект перенес бы объект сессии, который Вы используете для хранения URL перенаправления.
Методы, вероятно, были бы следующим образом (все общедоступные помехи):
- setRedirectUrl (представляют URL в виде строки),
- doRedirect (представляют defaultURL в виде строки),
setRedirectUrl назвали бы в любом действии, которое производит ссылки / формы, которые должны перенаправить к данному URL. Поэтому скажите, что Вы имели, проекты просматривают действие, которое генерирует список проектов, каждого с задачами, которые могут быть выполнены на них (например, удалить, редактирование), Вы назвали бы RedirectClass.setRedirectUrl ("/project/view-all") в коде для этого действия.
Затем позволяет, говорят, что пользовательские щелчки удаляют, они должны быть перенаправлены к странице представления после удалить действия, таким образом, в удалить действии Вы назвали бы RedirectClass.setRedirectUrl ("/project/view-all"). Этот метод надеялся бы видеть, была ли переменная перенаправления установлена на сессии. Раз так перенаправьте к тому URL. В противном случае перенаправление к URL по умолчанию (строка передала setRedirectUrl методу).
Я соглашаюсь с "rmbarnes.myopenid.com" относительно этой проблемы, как являющейся независимым от платформы.
Я сохранил бы страницу URL вызова в QueryString или в скрытом поле (например, в ViewState для ASP.NET). При хранении его за пределами объема страницы (такого как Сессия, глобальная переменная - Состояние приложения и так далее) затем, это не будет просто излишество, как Tom сказал, но это принесет Вам проблему.
Какая проблема? Проблема, если у пользователя есть больше чем одна вкладка (окно) того открытого браузера. Вкладки (или окна) того же браузера, вероятно, совместно используют ту же сессию, и перенаправление не будет ожидаемым тем, и весь пользователь будет чувствовать, то, что это - ошибка.
Мои 2 евроцента..
Я лично сохранил бы необходимую информацию о перенаправлении в объекте и дескрипторе глобально. Я избегал бы использования QueryString param и т.п., так как они могли попытаться возвратить себя назад к странице, к которой они не предполагаются (возможная проблема безопасности?). Вы могли затем создать статический метод обработать объект перенаправления, который мог считать информацию и действие соответственно. Это инкапсулирует Ваш процесс перенаправления в одной странице.
Используя объект также означает, что можно позже расшириться, это при необходимости (такие как добавляющий возврат обменивается сообщениями и другая информация).
Например (это - 2-минутная грубая инструкция 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;
}
}