Зачем нужны throw Exception?

[john.brown]

zerkms
А при чем тут капча? Вот она точно никак не связана с моделью. И проверяется контроллером.

гхм, я как-то думал, что ты "за" валидацию моделью.
тогда твоя позиция оказывается совсем непонятной.

Может так станет понятнее?

class Model extends ModelBase {
	private $keys = array('id', 'name', 'password');
	
	public function fill() {
		foreach($this->keys as $key) {
			$this->{$key} = $this->api->request->get($key);
		}
	}
	public function save() {
		$this->api->validator->validate($this);
		if(empty($this->id)) $this->insert();
		else $this->update();
	}
	public function getRules() {
		$rules = new validator_RulesSet();
		$rules->addField('id');
		$rules->id->addRule(new RequiredLength(0,11));
		$rules->id->addRule(new IsNumeric());
		$rules->addField('name');
		$rules->name->addRule(new RequiredLength(1,64));
		$rules->name->addRule(new IsPlainText());
		$rules->addField('password');
		$rules->password->addRule(new RequiredLength(6,255));
		$rules->password->addRule(new IsEqual($this->api->request->get('password_re')));
		return $rules;
	}
 }

Если данных там нет, то заполняем невалидными данными, в моем случае NULL. И получаем предсказуемый ексепшн.

П.С. был бы у нас более строгий язык, и разговор у нас был бы другой...

 

[Mols]

Чето всё равно не понятно каким боком подтверждение пароля относится к модели?
Ну видно что сюда за каким-то фигом вставлено это правило.
Но подтверждение пароля действительно также далеко от модели как и капча.

-~{}~ 20.06.10 17:50:

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

 

[zerkms]

А при чем тут капча? Вот она точно никак не связана с моделью. И проверяется контроллером.

Смысл разделять процесс процесс валидации? Капча - это такой же пользовательский ввод, как и повтор пароля.

Дальше:
Авторизация пользователя. Ввод обоих полей обязателен (логин и пароль).
Что и как будем валидировать? Какую модель в этом случае будем заполнять? Или это очередное "исключение" из правил, как и капча?

Может так станет понятнее?

да, мне стало понятнее, что твоя модель знает об объекте запроса (омг)

$this->{$key} = $this->api->request->get($key);

 

[john.brown]

Mols
Ну как же далеко? Пароль ведь является полем модели? А подтверждение является контрольным значением для провеки его валидности? Или подтверждение для чего то друго вводится? Тогда поделись, для чего в форму подтверждение пароля пихают.

 

[zerkms]

Пароль ведь является полем модели?

является, да. а подтверждение является полем модели? если да - тогда где оно в keys. а после того как добавим - опиши как будет работать

if(empty($this->id)) $this->insert();
else $this->update();

после того, как мы в keys добавим несуществующее в базе поле ))

 

[john.brown]

zerkms
И что с того? Объект запроса является частью общего для приложения Core API, которое доступно любому классу через $this->api - и что в этом плохого?

-~{}~ 20.06.10 19:01:

zerkms

подтверждение является контрольным значением для провеки его валидности

Ты просто поспорить хочеш, или как?

 

[zerkms]

И что с того? Объект запроса является частью общего для приложения Core API, которое доступно любому классу через $this->api - и что в этом плохого?

Омг... давайте скатимся ещё до глаболсов в этом ранее достаточно грамотном обсуждении. Плохого в этом то, что модель не должна работать с запросом. Почему не должна? потому что с запросом должен работать контроллер. почему он? потому что паттерн такой. почему паттерн именно такой? чтобы уменьшить связанность компонентов. зачем уменьшать связанность? затем - что чем меньше связанность - тем проще код разрабатывать, поддерживать и тестировать ))))

Ты просто поспорить хочеш, или как?

Эм.... а какая изначально у этого треда была задача, кроме как поспорить (и определить истину)? Пока в процессе дискуссии ты только придумываешь исключения, дабы своё решение заставить работать с обычными вполне ситуациями, вместо того, чтобы валидировать всё однообразно.

Вопросы выше про валидацию формы аутентификации

Дальше:
Авторизация пользователя. Ввод обоих полей обязателен (логин и пароль).
Что и как будем валидировать? Какую модель в этом случае будем заполнять? Или это очередное "исключение" из правил, как и капча?

и про поля

является, да. а подтверждение является полем модели? если да - тогда где оно в keys. а после того как добавим - опиши как будет работать

if(empty($this->id)) $this->insert();
else $this->update();

после того, как мы в keys добавим несуществующее в базе поле ))

по-прежнему в силе

-~{}~ 21.06.10 02:10:

Ну что ж, продолжим

И получаем предсказуемый ексепшн.

Эксепшн от какой модели? Которая первая валидировалась?? А если в запросе от пользователя пришли данные для заполнения трёх моделей. мы заполнили все три с ошибками. тогда будет отвалидирована только одна из них? и в форме будут подсвечены ошибки только для одной? а после исправления для второй?

торжество проектирования UI )))

 

[Mols]

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

в форму подтверждение пароля пихают

А не в модель.
Да и вообще отождествлять модель с формой странно.
Вроде Вы понимаете (на примере капчи) что модель и форма вещи разные.
А через пост пишите мысль "если подтверждение пароля находится в форме значит оно часть модели"
Самому не смешно?

 

[craz]

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

 

[varan]

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

 

[korchasa]

Автор оригинала: varan
Ибо это же не просто проверка на то что две некие строки совпадают, это проверка на то, что пользователь запомнил пароль, т.е. часть бизнес логики

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

 

[zerkms]

varan
правильно, это бизнес. а кто сказал, что бизнес должен быть в модели?

 

[varan]

Модель - это ведь от слова моделировать? А что мы моделируем, если не бизнес?

 

[zerkms]

Моделировать от слова модель, наоборот Модель это отображение бизнес-сущности в приложении, но совсем не обязательно бизнес-процесса. Обычно эти 2 задачи разделяют, потому что они слишком уж разные. Разделяют соответственно в сервисный слой, который содержит бизнес-логику

Более того - как заметил korchasa, эта задача может быть выполнена даже на клиенте (джаваскриптом) - и вот тут уже никаких моделей даже, чистый View.

 

[varan]

понятно, это разница в терминологии. Я под моделью понимаю всё: и логику и сущности. А уж как они там организованы, слоями или винегретом - дело десятое

 

[zerkms]

varan
На той странице была занимательная беседа насчёт валидации в модели и капче

 

[fisher]

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

логику программы эксепшн разрывает напрочь - теряется смысловой "контекст", на момент обработки состояние объектов скорее всего неконсистентно и тд. поэтому надо осторожно.

а теперь почему валидация через эксепшены - зло. юзеру надо показать разные текстовые ошибки на разные ошибки ввода, а форма, допустим - большая. бритва оккама подсказывает, что состояние формы - это например хэш или индекс не прошедших валидаторов и просто нужен внешний хэш соответствия код-ошибки - текст-ошибки, чтобы юзеру показать нужное. это какбе очень всё просто - а раз просто то так и надо (не требуящая доказательства великая мудрость программирования). но если мы следуем "правилам" (не передавать код - использовать класс ошибки) - то этот код превратиться в месиво проверок, поймай СлишкомКороткоеИмя, поймай СлишкомДлинноеИмя, ТебеЕщёРаноДеточка и так далее. Зато объектно! Можно передавать дополнительно код - но тогда чем это всё отличается от обычного дизайна валидатора? Правильно, удобным написанием без кучи ветвлений. Вот они базовые ценности.

 

[korchasa]

Автор оригинала: fisher
то этот код превратиться в месиво проверок, поймай СлишкомКороткоеИмя, поймай СлишкомДлинноеИмя, ТебеЕщёРаноДеточка и так далее.

Там не с этим проблема, эту можно решить через базовое исключение ОшибкаВалидации, и наследование от него. Там проблема в том, что вызов каждого check($rule) придется оборачивать в try...catch, чтобы поймать множественные ошибки. И тут уж действительно непонятно зачем исключения.

 

[fixxxer]

Валидация пользовательского ввода - это задача, для решения которой исключения не подходят, по очень простой причине.

Валидировать мы должны (если, конечно, мы пишем для людей) всю форму целиком, а не поднимать лапки вверх при первом же некорректном вводе. И единственный способ тут принянуть за уши исключения - это делать new ValidationException(array of (field => error_code)), притом сразу же уровнем выше мы это исключение словим. Ничем от обычного if-а не отличается.

А вот для какого-то внутреннего API, где первый же некорректный символ - это нарушение протокола и до свидания, вот тут - да, вполне можно.

И, собственно, само определение "исключительная ситуация" намекает.

-~{}~ 21.06.10 20:12:

При этом я, кстати, не исключаю ситуации, когда тот же датасет может валидироваться и в рамках API-вызова. Но тут уже сначала проводим валидацию как всегда, а потом на уровне api call contoller-а кидаем исключение "неверный вызов API". В самом непроходе валидации ничего исключительного ведь нет, исключительная ситуация тут именно в контексте апи возникает.

 

[grigori]

так я и делаю: форму проверяю обычными проверками, и вывожу сообщения об ошибках над полями ввода,
а в методах, которые работают с базой, пишу отдельную проверку с выбросом exception, например
if (!is_int($param)) throw pException(610);

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

вот этот эксепшен ловится на верхнем уровне, пишется в лог и делается location: /error.html