Gridview, и эта надоедливая кнопка браузера назад - PullRequest
Новая
       15

Gridview, и эта надоедливая кнопка браузера назад

1 голос
/ 07 ноября 2011

На нашей странице ASP.NET есть GridView с некоторыми данными, а в одном столбце есть флажки для выбора строк. Кнопка «Удалить» существует под GridView. Когда конечный пользователь выбирает некоторые элементы с помощью флажков, а затем нажимает кнопку «Удалить», запускается обратная передача и удаляются выбранные элементы. Довольно распространенный материал.

Проблема, которую мне назначили, также распространена. Если на полученной странице конечный пользователь нажимает кнопку возврата в браузере, то (после предупреждения, которое всегда игнорируется), повторная отправка запускается повторно.

Проблема здесь в том, что, поскольку выбранные элементы уже были удалены, браузер просто выбирает те строки, которые сейчас занимают место, где был удаленный элемент, и продолжает вместо этого удалять эти элементы. Это плохая вещь ™.

До сих пор я разбирался с некоторыми идеями, основанными на установке и проверке переменных Session, чтобы попытаться отследить, произошла ли обратная передача, но я пока не слишком доволен результатами.

У кого-нибудь есть хороший (и, надеюсь, простой) способ решения этой проблемы?

Ответы [ 3 ]

0 голосов
/ 08 ноября 2011

Я не думаю, что есть легкий путь.

Вы можете поиграться с javascript и попробовать различные настройки кэша http-браузера, но вы не можете полностью полагаться на них. Вы должны предположить, что пользователь сможет повторно опубликовать форму.

Я думаю, что вы правы, когда имеете дело с этим в коде сервера. Как насчет этого:

Создать переменную cookie / сессии в GET страницы сетки. Сделайте недействительной эту переменную cookie / session в POST страницы сетки.

Таким образом, при повторной отправке через кнопку возврата ваш код должен обнаружить отсутствие допустимого значения cookie / сеанса, а затем повторно выполнить перенаправление на ту же страницу, вызывая GET.

PRG Pattern.

Звучит так, как будто вы уже используете шаблон Post-Redirect-Get, когда упоминаете «полученную страницу» из обратной передачи. Если это не так, то это помогает решить другую проблему, когда пользователи нажимают клавишу F5 в опубликованной форме.

Удачи!

0 голосов
/ 08 ноября 2011

Вы также можете поместить некоторое значение в viewstate вместе с сеансом на первом! IsPostback, а затем изменить его на что-то другое в IsPostback.

Это может быть проще, чем файлы cookie или файлы с истекшим сроком действия кэша браузера.

В этом случае, если пользователь нажимает кнопку «Назад» и отправляет что-либо, вы можете посмотреть на viewstate и увидеть, соответствует ли оно значению в сеансе, если нет, то выслать пользователя на вечность.

Это, очевидно, предполагает, что вы используете традиционный asp.net с включенным viewstate.

Надеюсь, это поможет.

0 голосов
/ 08 ноября 2011

Как насчет асинхронного удаления записей в GridView? (используя панель обновления)

Это предотвратит сохранение браузером выбранных флажков в кеше браузера и удалит раздражающую проверку безопасности всплывающего окна браузера всякий раз, когда пользователь обновляет страницу после полной обратной передачи.

Или случайно вы пробовали снять все флажки в коде после первой привязки? (скажем, на Page_Load)

попробуйте это: 

<asp:UpdatePanel id="upGv" runat="server" ChildrenAsTriggers="false" UpdateMode="Conditional">
    <ContentTemplate>
        <asp:GridView ID="gv" runat="server" />
        <asp:Button ID="btnDelete" runat="server" Text="Delete" />
    </ContentTemplate>
</asp:UpdatePanel>

в коде позади: 

Private Sub btnDelete_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles btnDelete.Click
    ' do a for loop searching for selected checkboxes and do the deleting here
    ' --- delete codes ---
    ' rebind the data in gridview
    gv.DataSource = 'some dataset/datatable etc etc
    gv.DataBind()
    'update the updatepanel
    upGv.Update()
End Sub
...