Выпустив сегодня AJAX.NET BETA 2, мы увидели, насколько быстрой и эффективной является тесная интеграция AJAX и ASP.NET 2.0. Мы даже можем сделать веб-страницы ASP.NET более эффективными, не написав ни единого обновления кода. бесплатный эффект достигается часами написания кода JS. Все это очень легко интегрировать в ASP.NET. Вам нужно всего лишь переместить элемент управления в элемент управления UPDATEPANEL и установить несколько параметров. Однако, испытывая удобство, которое AJAX.NET приносит разработчикам, вы также обнаружите, что AJAX.NET иногда не идеален. Точно так же, как автор недавно столкнулся с ошибкой в элементе управления входом в ASP.NET 2.0, которая обновляет страницу после успешной проверки информации о пользователе в UPDATEPANEL. Очевидно, это нарушает принцип AJAX без обновления. После анализа информации о пользователе, встроенной в элемент управления входом, The. метод проверки идентификационной информации обнаружил следующий код:
Private void AttemptLogin()
{
LoginCancelEventArgs args1 = новый LoginCancelEventArgs();
this.OnLoggingIn(args1);
если (!args1.Отмена)
{
AuthenticateEventArgs args2 = новый AuthenticateEventArgs();
this.OnAuthenticate(args2);
если (args2.Authenticated)
{
//После успешной проверки информации о пользователе записываем информацию COOKIE для клиента.
FormsAuthentication.SetAuthCookie(this.UserNameInternal, this.RememberMeSet);
this.OnLoggedIn(EventArgs.Empty);
//Проблему вызывает следующий оператор Response. Выполнение операции перенаправления в элементе управления UPDATEPANEL приводит к обновлению страницы!
this.Page.Response.Redirect(this.GetRedirectUrl(), false);
}
}
}
Анализируя метод AttemptLogin, нетрудно увидеть, что когда мы нажимаем кнопку входа в элементе управления Login и успешно проверяем информацию о пользователе, будет выполнен оператор перенаправления страницы Response.Redirect (этот код будет выполнен, даже если перенаправление page не указана, а значением по умолчанию является текущая страница), и именно из-за перенаправления страницы страница обновляется. Как только вы узнаете причину ошибки, ее будет легче устранить. Возможно, кто-то скажет, что пользовательский элемент управления может наследовать элемент управления Login и переопределить метод AttemptLogin. Но есть ли более простой способ, кроме пользовательских элементов управления? Ответ — да. Поскольку именно встроенный механизм проверки вызывает обновление страницы, просто не используйте обработку проверки элемента управления входом, а используйте собственный метод для проверки личности пользователя. Во-первых, чтобы использовать собственный метод проверки, мы сначала находим элемент управления Login и преобразуем его в шаблон. Затем мы находим элемент управления LoginButton в шаблоне и удаляем CommandName="Login", чтобы элемент управления больше не использовал встроенный метод. in для проверки. Теперь, когда у нас есть информация о пользователе, давайте добавим событие OnClick в LoginButton. Код выглядит следующим образом:
protected void LoginButton_Click (отправитель объекта, EventArgs e)
{
//Проверяем правильность имени пользователя и пароля
если (Членство.ValidateUser(Логин1.Имя пользователя, Логин1.Пароль))
{
//Согласно приведенному выше анализу механизма проверки входа в систему, напишите COOKIE для клиента.
FormsAuthentication.SetAuthCookie(Login1.UserName, Login1.RememberMeSet);
//После успешной проверки вы можете выполнить здесь некоторую обработку, например скрыть элемент управления входом.
Логин1.Видимый = ложь;
}
еще
{
//Поскольку встроенный механизм проверки не используется, обработку ошибок проверки необходимо настроить самостоятельно.
(Login1.FindControl("FailureText") как Literal).Text = "Имя пользователя или пароль неверны, попробуйте еще раз!";
}
}
Проанализируйте приведенный выше код. Информация о пользователе, которую необходимо проверить с помощью элемента управления входом, хранится в таблице aspnet_membership базы данных Aspnetdb SQL2005. Таким образом, мы можем легко проверить информацию о пользователе, используя метод Membership.ValidateUser. проверка прошла успешно, следуйте приведенному выше анализу. Метод AttemptLogin записывает COOKIE для клиента, а затем устанавливает сообщение об ошибке проверки. Затем мы можем легко преобразовать наш элемент управления входом, чтобы он больше не обновлялся после успешной проверки информации о пользователе. Преимущество этого преобразования. заключается в том, что нет необходимости писать собственный элемент управления. Элемент управления такой же сложный, как и исходный элемент управления входом, и эффект точно такой же, как и исходный элемент управления входом. Имя пользователя, созданное элементом управления CreateUserWizard, по-прежнему можно использовать для проверки, и элементы управления. связанные с элементом управления входом в систему, такие как LoginStatus и LoginName, также можно использовать как обычно.
PS: Если исключение PageRequestManagerParserErrorException возникает, когда элемент управления входом проверяет информацию пользователя, проверьте, содержит ли web.config это предложение:
.....
Спасибо, блюдце, за напоминание
http://www.cnblogs.com/aspxcn/archive/2006/11/07/552927.html