Я довольно анал о проверке формы. Поэтому, создавая валидатор для поля "данные рождения" (DOB) в одном из моих текущих проектов для формы заявки на работу (платформа/язык в этом контексте нейтральна), я хотел, чтобы что-то предотвратило "случайные" входы.
Я использовал сборщик дат и ограничил максимальную дату XX лет с текущего дня. XX имеют смысл для этого сценария, поскольку кто-то младший не должен даже претендовать на работу.
Сообщение об ошибке проверки: вы слишком молоды для задания.
Тогда я начал приходить в авантюру. Как насчет?
Если DOB более 120 лет назад, сообщение: "Вы не можете быть старым!!!"
Если DOB в будущем, сообщение: "Вы, должно быть, шутите, вы еще не родились!!!"
В конце концов, я развернулся без последних двух, слишком нахальный для моего беззаботного клиента.
Я хотел бы знать, как далеко вы, ребята, пошли бы проверять поля DOB для хорошего удобства (или юмора)?
Аналогично для таких дат, как "Дата вступления в брак", "Год окончания" и т.д.
PS: Поскольку я собирался отправить это сообщение, там появляется предупреждение под заголовком textbox: "Вопрос, который вы задаете, кажется субъективным и, скорее всего, будет закрыт". Пальцы пересекли.
Чтобы добавить: Я очень удивлен тем, что некоторые/большинство парней не слишком заботятся о проверке. Я повторяю один из моих комментариев здесь:
Если пользователь неверно ввел дату (что-то очень очевидное) по намерению или по ошибке; что одна из целей валидаторов поймать его. Когда данные поступают в систему, владелец сайта знает, что вход неверен, он/она не знал бы фактического значения, не спрашивая пользователя. Если это поле очень важно, это будет не очень красивый сценарий.
Подумайте о времени, когда вы заполнили формы. Сколько раз вы были расстроены, потому что какой-то "слишком умный" программист вставил какую-то "проверку", которая просто оказалась неправильной для ваших обстоятельств? Я говорю, доверяй пользователю. Подумайте об этом, со временем я думаю, что люди живут дольше и становятся в сети в более раннем возрасте.: P
Не забывайте, что вы также можете предупредить пользователя о маловероятных значениях. В большинстве случаев опечатка более вероятна, чем преднамеренное неудобство.
Итак, для вашего приложения может быть что-то вроде этого:
Проверка и правильность
Точка проверки ввода - это обеспечение того, чтобы все элементы находились в пределах допустимого и ожидаемого диапазона путем дальнейшей обработки - т.е. Если ваша база данных гарантирует, что все кандидаты в БД составляют 18 лет или старше, подтвердите это. Если ваша база данных также принимает школьников, подающих заявку на стажировку, не делайте этого.
Все необычное - это просто предупреждение. Да, значение 120 лет сумасшедшее, вы должны предупредить пользователя и, возможно, пометить эту запись как подозрительную/для обзора. Однако нет смысла отказываться от него (если у вас нет бизнес-правила, например, все заявители моложе 70 лет).
Поддельное доверие
Представьте, что произойдет, если вы сообщите одному пользователю, что "вы исключаете маловероятные DOB на входе". Она может сказать своему сотруднику, что DOB "уже проверена". Он заканчивает необоснованным доверием, что заявителю 90, и если бы это была подделка, вы бы его отвергли.
Вся дальнейшая обработка - человеком или компьютером - должна все же предполагать, что DOB может быть неправильным - только из-за опечатки. Вы пытаетесь создать гарантию, которую вы действительно не можете сделать. Многие пользователи доверяют компьютеру, который они используют каждый день больше, чем незнакомец, вы пытаетесь обеспечить это доверие, что является ошибкой ИМО.
Трансмутация
Многие приложения живут намного дольше, чем предполагал первоначальный реализатор, и некоторые из них будут использоваться для целей, выходящих за рамки его самых смелых мечтаний. Создание в искусственных пределах, которые ни упрощают фактическую обработку, ни работу оператора фактически не помогают.
(Это ставит меня, вероятно, в категорию беззаботности вашего клиента - но мой способ быть "анальным в отношении проверки": знать, когда остановиться:))
Я считаю, что валидация невероятно важна, но не обязательно в вашей ситуации. Что не означает, что ваша ситуация тривиальна, у меня просто есть свои собственные ориентированные на дату ницы.
В частности, мои проблемы всегда в том, чтобы держать вещи в логическом порядке. Если кто-то говорит, что они родились в 1802 году, этот штраф (sorta), я просто хочу, чтобы их дата окончания была больше, чем их дата рождения. Но вы сталкиваетесь с зудными проблемами, когда дело доходит до времени (например, в часах и минутах), например, если пользователь выбирает 8:30 в качестве времени начала, а затем выбирает 9:15 в качестве конечного времени, но затем понимает, что время окончания - 8:45. Они решили изменить 9 на 8 с целью изменения минут до: 45. Но моя проверка script слишком занята, говоря: "Эй, подожди! 8:15 до 8:30, хорошая попытка!" но я не могу рисковать позволить им оставить это неправильно и т.д. и т.д.
Для конкретной ситуации я склоняюсь к тому, что является этическим правом. Потому что, как указывалось, кто-то может войти в семейную историю (с DOB в 1600-х годах) или будущие покупки (с датами после сегодняшнего дня), поэтому нет реального предела для дат в целом. Но есть ли ограничения для вашего сценария, то есть:
Если возраст меньше легального трудоспособного возраста (16 в большинстве районов США), даже не предлагайте ничего выше, чем этот год в качестве варианта (если вы используете раскрывающийся список).
Если возраст за пределами разумного трудоспособного возраста (который может быть чувствительным предметом), предлагайте наивысшую ценность на основе пенсионного возраста и просто добавьте " > " перед этим годом. Если кому-то 75 и подают заявку на работу на уровне администратора, они будут более довольны тем, что вы сделали вещи просто, а не оскорблены тем, что не указали свой год рождения. Во всяком случае, они будут впечатлены (я думаю), что вы отправились на этот маршрут вместо ничего, подразумевая, что они не должны тратить свое время.
В итоге у вас есть простой выпадающий список очень простой script (пример в PHP):
$currentYear = date('Y');
echo "<select name=\"YearOfBirth\">";
for($i = 16; $i <= 64; $i++) {
$optionYear = $currentYear - $i;
echo "<option value=\"$optionYear\">$optionYear</option>";
}
$greaterYear = $currentYear - 65;
echo "<option value=\">$greaterYear\">>$greaterYear</option>";
echo "</select>";
Когда вы спрашиваете живых людей о своей родине, только отклоняйте значения, которые определенно ошибочны. Любая дата рождения в будущем определенно неверна. И я бы нарисовал линию и сказал, что любая дата рождения до (скажем) 1880 года определенно неверна. Все остальное является действительной датой рождения.
Таким образом, любая дата рождения, которая терпит неудачу в вышеуказанных тестах, отклоняется с сообщением на полевом уровне, например: "Эта дата в будущем/слишком далеко в прошлом. Пожалуйста, введите дату своего рождения".
Любая другая дата рождения действительна (может быть, пользователю действительно 11 лет или 108). Но общая форма может быть отклонена бизнес-правилами. Например, "Вам должно быть не менее 18 лет, чтобы подать заявку".
Идея состоит в том, чтобы отделить отдельную проверку поля от проверки формы. Конфигурация их приводит к сложным правилам. Разделение означает, что вы можете повторно использовать правила для поля (например, "DOB живого человека должно быть между 1/1/1880 и сегодня" ) в других контекстах.
Если вы делаете это для чего-то профессионального - как приложение для работы - я не могу использовать "!" в сообщениях пользователям. Взгляните на любой хорошо сделанный веб-сайт, который вы хотели бы, вы не найдете его в обычном использовании.
Действительная дата: проверьте
Дата не в будущем: может быть (я занимаюсь медицинскими приложениями, поэтому, полагаю, вы могли бы лечить нерожденных детей)
Дата не старше 120 лет: возможно
Я не большой поклонник чрезмерного проектирования этих вещей, особенно если ошибка пользователя относительно безвредна и может быть легко обнаружена и исправлена. То, что я все равно подхожу к нему.
Действительная дата:
Я рассмотрю, существует ли эта дата или нет. т.е. скачок 29-го февраля и т.д.
Дата в будущем:
мы обычно проверяем возраст (в этом году - дам) и должны быть хотя бы определенный возраст для регистрации.
Дата старше 120 лет или нет:
Я не проверю. 200 лет - более безопасный лимит? (в случае, если 121-летний мужчина хочет использовать компьютер *chuckles*)
Я думаю, что вы должны учитывать свои фактические требования при разработке валидаций. Да, если поле является полем даты (и, возможно, более важно, если оно хранит дату, но некоторые менее звездные dba сделали его varchar), убедитесь, что отправлена действительная дата. Это важно. Недействительные даты вызывают всевозможные проблемы с запросом данных. Если это дата, которая по необходимости должна была произойти в прошлом, ограничьте диапазон дат текущей датой или ранее.
После этого идите с тем, чего хочет ваш клиент. Если они хотят заплатить за вас, чтобы уничтожить людей моложе трудоспособного возраста, они скажут вам. Запрет на верхний предел возраста может привести к возникновению юридических проблем для дискриминации по возрасту. Возможно, клиент не хочет, чтобы вы это делали.
Юмор - довольно субъективная вещь и очень конкретный проект, поэтому немного сложно ответить на эти темы. Сказав это, если приложение поддерживает формальный процесс, например, применение идентификатора задания, вероятно, ошибается на стороне осторожности и сохраняет его довольно фактическим.
Что касается проверки, я считаю, что усилия, с которыми вы переходите сюда, должны быть пропорциональны влиянию недействительных данных, пробивающихся из пользовательского интерфейса. Возвращаясь к форме заявки на работу, я предполагаю, что в какой-то момент будет процесс рассмотрения людей, поэтому риск недействительных данных будет минимальным, если данные были намеренно или непреднамеренно введены неправильно.
Если вы беспокоитесь о "плохих" или управляемых ботом входах, используйте Captcha. Сказав все это, я считаю, что вы достаточно безопасны с правилами валидации, которые вы использовали.
Ну, я не программист (больше BA), хотя я пытаюсь получить некоторые навыки развития, поскольку я думаю, что это может помочь мне стать лучшим BA. Я сделал немного VBA (не смейтесь).
В любом случае, думая об этом, мои два цента
1) Снижение юмора. Что смешно вам сейчас не будет для кого-то другого. Кроме того, что смешно после двух или трех идет не смешно после 25 или 30 - его просто утомительно, даже если вы имеете дело с толпой! 2) Я прихожу к идее, что, если вы не можете окончательно подтвердить что-то, как просто неправильное, например. вы не хотите, чтобы кто-то вводил значение < 0, тогда вам следует рассматривать предупреждение, а не предупреждение через диалоги или что-то вроде стандартного ОС.
Эй, что я знаю, через неделю я передумаю (я - бизнес-аналитик) и буду требовать мгновенные репсоны от разработчиков, →
Позвольте просто использовать двузначные годы. Никто не будет использовать наше программное обеспечение после 1999 года!
Будучи перфекционистом, я бы пошел сюда за 150: D
как можно меньше шансов, люди прошли 120, и кто знает, что произойдет в ближайшие 30 лет: D
Я не считаю это тем более важным.
Все зависит от приложения. Приложение бизнес-приложения (LOB) для обработки заказов очень отличается от отслеживания исторических или будущих данных.
Можно согласиться с тем, что он должен быть действительной датой, но считайте, что существует несколько календарей (например, число месяцев может быть 13, год может быть более 5000).
Подтвердить для целого числа и быть полезным; Я думаю, что что-то еще: система оскорбительного/большого брата/над-enginereed - плохая идея.
Людям должно быть позволено лежать на этих формах, если они того пожелают; это не юридическая вещь, это веб-сайт.
Не относитесь к этому так серьезно.
Просто дайте пользователю выбрать дату. Пользователь должен быть в контроле.. не система/разработчик. Единственная дата, которую следует избегать в отношении DOB, - это будущее, поскольку это неверно (т.е. Предотвращение ошибок по дизайну). Предложенный вами механизм выбора даты должен обрабатывать любые проблемы формата даты.
И определенно не бросайте никаких нахальных исключений/сообщений. Ваше сообщение должно помочь пользователю в распознавании и восстановлении после ошибки.
Надеюсь, что это поможет.
Ниже приведены проверки, которые вы можете выполнить при проверке DOB:
рассчитать возраст от DOB и выполнить следующие проверки
ВОЗРАСТ > XX [XX - минимальный возраст, требуемый для применения]
AGE < XX {Должно быть брошено сообщение о том, что вы недостаточно взрослые}
ВОЗРАСТ = XX
Если нет верхнего предела возраста, тогда мы можем взять его в качестве возраста выхода на пенсию, чтобы проверить его с верхним пределом для следующих двух проверок.
AGE < Пенсионный возраст
ВОЗРАСТ > Возраст на пенсию {Должен бросить сообщение о том, что вы слишком стары, чтобы применить}
ВОЗРАСТ = возраст выхода на пенсию
DOB - действительная дата (давая действительную дату)
DOB недействителен -
Enter 0 in either of day/month/Year
Enter some negative Value
Enter some invalid date e.g. 30th feb or 32 Jan etc
Enter valid date with different separators (although the date is a valid one but due to different separators it will become an invalid one)
Введите дату в разных форматах, например, указав dd/mm/yyyy, dd/mm/yy, dd/MON/yyyy и т.д.
Введите некоторую будущую дату (здесь недействительно, поскольку ваша цель - это нечто иное)