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

Это сообщение отредактировал(а) y3u - 30.11.2006, 00:45

Предисловие:
 - они сделают только косметические дейсвия без завязки на огромный запас данных, которые в БД. А мы говорим как раз о данных...






Фффух... ну тогда я просто не понимаю упорного тяготения к красоте скрытия кнопочки.....

Задизабленная кнопка решает только двойной клик на машине, клик на соседней машине она не решит в принципе.



Это весьма полезно и стоит это применить(способ действительно полезный и проверенный). Но это скорее доп. защита от шаловливых ручек ("НУ НЕ ТЫКАЙ ТЫ ТУДА! - ВИДИШЬ? - ГРУЗИТСЯ!!! СИДИ ЖДИ!!"). Напишу ещё.


Но если это промышленное приложение и у него есть критичные условия(что естественно) - тогда стоит поглядеть на него не со стороны браузера, а со стороны функциональности и логики работы.

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

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

Ярко выделяются два направления(не учитывая остальных):
Те, кто пересел с ПХП на джаву как инструмент написания вэб-движков. И мыслит категориями динамических страничек. Как правило, первый путь: хэлло-ворд -> сервлет хелловорд. Далее идёт спуск в глубь джавы "ух ты... так тут ещё и не только странички...".
И те, кто пересел с сипипи и близких к нему. Тут человек поглядывает немного искоса на вэб и пишет десятки програмулек, радуется как ребёнок обилию коллекций, полезных библиотечек и пакетиков , а потом с подозрением встречает развесёлую компанию сервлетов и джсп.
Потом различия нивелируются, многие идут совершенно своим путём, но моя подсознательная имха такова.

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


Вобщем, поехали:

У нас есть несколько уровней где мы можем противостоять хаосу:

• Есть наша любимая кнопка на страничке. Дизаблим. Отлично
• Есть логика на сервере(в сервлете), которая проверит есть ли уже такая запись в БД
• Есть уникальный констрэйнт в БД и ДиБиЭррор при вставке.

1) Пощупаем базу - констрэйнт нужен? - ДА! Как бы мы не напортачили в коде, наша верная старушка-БД не позволит в бедлама в своём домике. Хоть сто тыщщ ксепшнов посыпется на её голову, она не позволит испортить безвозвратно важные данные банальной перезаписью.
Главное - попросить её приглядеть за данными, создав уникальный констрэйнт
Итак, это - нужно

Но тут сидит ещё один нюанс... чтобы работать, опираясь только на один констрэйнт - надо отлавливать ошибку и обрабатывать её сверху как обсуждалось выше...
Нюансов становится два:

• Надо опираться на специфические эксепшны БД. Что будет, если сменится версия БД или сама БД?  Вдруг она перестанет бросать ТАКОЕ, или будет что-то невнятное Бросать? Когда мы поймём в чём у нас нестыковка? Сколько пройдёт времени? Доволен ли юзер будет красивым УИ при том, что он битый час пропотеет над созданием себя и просмотром непонятных сообщений о непонятных проблемах в системе?
•  УПРАВЛЕНИЕ ПРОГРАММОЙ С ПОМОЩЬЮ ЭКСЕПШНОВ - ПЛОХОЙ СТИЛЬ Это не означает что эксепшн - зло. Это как боль в человеческом организме - сообщает что что-то не так, как надо. Там, где происходит что-то непредвиденное(ПРОПАЛ СЕРВЕР БД!!   ) - впору орать трёхэтажными эксепшнами. Но кто сказал что что совпадение - это неправильно? 
  Пришёл правильный человек, сел за правильную систему, ввёл желаемый логин, такой логин уже есть - что тут неправильного?
  Мы не догадывались что это будет нормальная рабочая ситуация? 
  Враки!!! Вё мы прекрасно знали. Мы знали что тысячи КОль и каждый захочет своё имя сделать логином. 
  Если мне прищемили дверью руку - да, я заору. А если дверь просто закрыта - чему болеть? закрыта и закрыта, её право. 
  
  Не стоит писать код по принципу "сейчас я разгоняюсь, влетаю в коридор, поворачиваю налево и на полном ходу влетаю в двери!! (дальше по Задорнову) А если... вдруг... никаких дверей... там нет.... вот тогда уже(зал понимает в чём дело)... наш человек(зал плачет) с матом и своей головой пробивает новое окно!(зал пацтульями)".
  Зашёл, поглядел есть ли двери(!), открыты ли(!), открыл(!) - зашёл. Зачем головой вперёд лететь в бетонную стенку и орать "мать вашу, двери-то, двери где?!?!" ?
  
  Исключать этого не стоит, перехватывать можно(лишняя инфа о crash'e никогда не лишняя), но стоит всегда помнить что это нестандартная ситуация.

2) Далее... можно определить метод проверки... оооо.. кажется оно...
Перед тем как ломиться в дверь - давайте проверять - а есть ли дверь? Нет двери - сообщите корректным нормальным сообщением юзеру что "двери нет", "пива нет", "туалет занят", "Маня вышла" etc. Зачем кричать что-то похожее на kernel panic??
Пусть внемлет ситуации и войдёт в другую дверь(выпьет водочки, пойдёт к Тане).

Тут логика не страдает - мы просто переносим наши логичные поступки из реального мира в мир абстракций и цифр.


3) Поднимаясь к самой верхушке айсберга....
Дизаблить кнопочку... вроде бы и не надо уже... но почему же не надо? Надо!

Главное не перепутать тёплое с мягким. Дизабл спасёт от нескольких вещей.
Во-первых, не позволит человеку по глупости/спешке исскуственно создавать глупые ситуации: Три раза кликнул - три раза попросил создать юзера(а нафея тебе столько? - спросит добрая фея). Пресечём такую попытку ещё в зародыше.
Во-вторых, такая вещица полезна при неких сложных сессионных работах. Создали мы временную запись в одной таблице, во второй, в третьей, что-то сложное посчитали на их основе, добавили ещё одну - а вот тут уже два раза клацать не надо!!!
Может человек добавляет платежи, и добавить платёж с суммой 20 он может хоть сто раз. Но клиент заплатил всего 20. Поэтому, пощёлкав по кнопке, он надобавляет 80, 120, 240 на счёт клиенту. Даже не подозревая ни о чём(Я просто разместил объяву!!! - ну, то есть, просто давил на кнопку!!!   ). Проверять на уникальность тут нечего... Ведь клиент мог и в самом деле 2 раза по 20 заплатить. Это только юзер знает. Похожую ситуацию разруливали как-то. Без вариантов. Полезно. Под сим подпишусь.


Итого, теперь я бы внимательно подумал...
В том числе и над фразой

(Как-то, вроде-бы, неплохо бы...)

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


Вот такая здоровая вышла оффтопина....   


Это сообщение отредактировал(а) chief39 - 30.11.2006, 16:01

Привет всем.

Сделал поле для хранения имени пользователя в бд уникальным. Ну и само собой теперь вылетает ошибка при попытке записать такое же значение.  







И теперь, при попытке создания 



Пишет, что exception java.sql.sqlexception has already been caught, но до этого места я нигде больше не ловлю sqlexception.
Смысл в том, чтобы при появлении значения в SQLException ex выводилась ошибка о существовании уже существующей записи.
И кстати везде обыскал, но у SQLException метода getErrorCode() так и не нашёл, как сказал Sherst

Хм. http://java.sun.com/j2se/1.4.2/docs/api/ja...#getErrorCode()
Должон быть.

Я немного не понял твой вопрос. Ты в коде делаешь обработку ЛЮБОГО исключения (catch(Exception e)). Поэтому, разумеется, SQLException в твоем коде уже никогда не будет выброшен наружу. Убери try/catch, и тогда в случае ошибки SQLException будет выброшен из saveToDatabase().

Это сообщение отредактировал(а) batigoal - 10.12.2006, 11:50

Sherst, 

По определению  public int getErrorCode()  это int тип, поэтому я не могу сравнить его значение с логическим значением и сделать 



Но так как errorCode возвращает the vendor's error code, то думаю, что его можно сравнить с нулём вот так




Так всё ловит, но это не есть гуд. Суть такова, что на странице регистрации сообщения об ошибке ввода данных выводятся на этой же странице, но только не сообщение о дублировании имени, т.к. приложение об этом узнает только когда попытается записать данные в бд. Сейчас сообщение "Nickname already exist" выводится на странице о неудачной записи данных, т.е. после попытки записи в бд, а мне нужно чтобы небыло перехода на другую страницу. Как сделать с переходом на другую страницу я само собой уже понял.

 

Это сообщение отредактировал(а) Zamuta - 11.12.2006, 23:32

Зачем ?
Смоделируй ситуацию когда происходит добавление 2-ух идентичных записей и посмотри чему равно значение errorCode. А дальше используй это значение для определения того что у тебя произошла ошибка связанная с дублированием записи.

Дальше, как я понял, есть общая страница ошибок,  но ты хочешь что бы в случае неправильной регистрации не было перехода на эту страницу, а все выводилось на странице регистрации или я не правильно понял? 

Согласен, щас попробую.



Да, ты правильно понял. У меня так и работает проверка корректного ввода данных имени, майла, пароля и проверки повтора ввода пароля (см. выше validate() ). Хотелось бы и на совпадение имён сделать вывод ошибки здесь же. Но логику пока так и не продумал. Т.е нужно подключиться к бд не перезагружая страницу и вывести на ней ошибку. 

Что бы что-то вывести нужно эту страницу перегрузить иначе ничего не получится.

Как бы сделал я 

метод класса по работе с БД:




Далее класс контроллер (UserHandler.java):
В нем делаешь переменную которая будет содержать текст ошибки: String errorDescription, пишешь get set методы для нее. Метод нажатия на кнопку:



Оформляем faces-config.xml 



Все это выводишь на jsp страничке. Описание ошибки будет такое 

В ПХП эта проблема решается ОЧЕНЬ легко. После вставки данных в базу нужно лишь послать заголовок браузеру о переадресации. Делается это так:
header("Location: http://site.com/thanks.html");

Этот метод работает просто замечательно. Разве нельзя нечто подобное на Java сделать?? Ведь нужно:
1. Послать заголовок
2. Отобразить след. страницу