PrimitiveRule, изменение внутренностей Form::addRule, checkRules и т.д.

[AlexeyDsov]

PrimitiveRule, вырезанный из #101. Оно мне понравилось и хочется заюзать.

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

Идея следующая

• Убираем из формы отдельный массив rule
• Делаем класс PrimitiveRule который болтается взамен в общем списке примитивов у формы, делаем что б валидировал Form'у через метод import
• не даём ему импортиться при вызовах Form::import*
• но импортим его при вызове Form::checkRules
• API расширяется, BC сохраняется
• Методы Form::addRule($name, $expression) остаются т. к. порой удобней использовать их
• Из изначальной задумки убрано свойство PrimitiveRule->form и соответственно метод PrimitiveRule::setForm, взамен них примитив ожидает что при импорте вторым аргументом будет передана форма.
• на всё про всё ушло:
  • час с небольшим на вырезание нужного кода из Миграция ошибки из Формы в Примитив #101,
  • еще 20 минут на тестирование и осмотр тестов (их не дописывал, т. к. они были написаны раньше на пару опечаток с ними поправил)
  • еще 20 минут на написание реквеста

[stev]

Убираем из формы отдельный массив rule

rule должны отрабатыватся после того как проимпортятся примитивы

в текущем варианте нужно будет дважны проходить по списку проверяя не Rule ? для импорта
а потом еще разок для рулей

• оверхед как не как, малый но есть

я бы оставил масив rule, чтоб не делать лишних пробежек по примитивам.

[pupkinV]

а помнится там был PrimitiveRuleTest. В нем, что ничего путного не нашлось?

[AlexeyDsov]

rule должны отрабатыватся после того как проимпортятся примитивы

С чего вдруг? Сделали ВСЕ импорты - вызвали проверку правил через checkRules прошли по всем Rule'ам.

а помнится там был PrimitiveRuleTest. В нем, что ничего путного не нашлось?

А что там есть такого чего нет в текущем тесте?

а кто то c конфигами и у них настройка таймзоны в объявлении класса

так в той теме и обсуждай

[pupkinV]

use exists

[pupkinV]

@stev есть в этом доля правды: добавляются отдельным методом, запускаются отдельным методом. Так зачем их сливать в один массив с примитивами, чтобы потом использовать хак instansof разделяя их. хм..
Да, checkRules при этом не пострадает если ошибки писать в один массив

[anisimovt]

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

[AlexeyDsov]

@anisimovt 1) BC не ломается. Form::addRule можно использовать всё так же дальше 2) Правила в таком виде как есть не могу использовать в EntityProto т.к. там задается только список примитивов. 4) Я не в восторге от работы с двумя массивами ошибок errors и violated в методах getErrors, hasError, markCustom и т.д.

[pupkinV]

соглашусь с @anisimovt import не просто притянут за уши, но единственный параметр который был теперь nill, а добавился $form который null при нормальном использовании =)
@AlexeyDsov все равно checkRules вызывает метод только у Rule. Может не будем в один метод склеивать 2. Это уже совсем не наследование.

[anisimovt]

Может это тогда проблема EntityProto, а не формы? Я не спорю что не ломается BC, но и мирится с тем что правила, которые что-то делают с примитивами, тоже становятся примитивами не хочется. И то что они не импортируютя и проверяются в другом месте тоже не красиво. Я не отрицаю саму идею, но может её можно сделать по другому? Честно сказать неудобства от работы с 2 массивами ошибок не испытвал, они всё равно объединяются в getErrors(). Ну и ожидание формы в методе импорта примитива совсем меня с толку сбивает

[AlexeyDsov]

@anisimovt таки убедил в переписке что оно для моих целей не стоит. в новом году сделаю некоторые изменения связанные с EntityProto