voronkovich: ну вы ж видели доки, там все, что касается таких параметров, как allow_extra_fields, всегда указывалось в резолвере, или в опциях при создании формы, через фабрику. А тут, вон, оказывается, нужно было положить в параметры типа, хотя в доках не указано. Ну короче странные вещи.
voronkovich: мне уже было лень копаться в исходниках, просто я так и не понял, тогда при чем allow_add к ошибке "This form should not contain extra fields" ?
voronkovich: проблема в том, что при true\false я не смогу получить точной причины отказа. То ли я не смог создать запись из-за прав, то ли из-за того, что что-то было не найдено и т.д. Если делать через проверку маршрута - это тоже проблема, потому что, вы же сами понимаете, маршрут может поменяться, а дублировать все роуты в сервисе, не кажется мне хорошим делом.
Еще мне кажется вместо аннотаций (вы писали ниже), можно было бы добавить параметром в роуте, путь к классу, который будет проверять значения, перед передачей их далее, в action. Хз, в общем, пока буду делать через сервисы.
Значит типовые задачи выношу в менеджер, эти типовые задачи обеспечиваю своими исключениями, которые перехватываются в RequestSubscriber-e, который в свою очередь их преобразует в корректный Response. Я так понял ?
shagguboy: насчет Listenera-a я имел ввиду, что не представляю, как организовать в нем логику работы с типовыми запросами по определенным урлам. Вы целиком вопрос читали ?
Ага, понял вас. Ну в принципе можно тогда создать какой-нибудь сервис "PermissionResolver" в котором копить методы для проверки на условие и кидать в случае несоответствия - Exception. Просто мне эти проверки нужны еще и на стороне twig шаблона, для отображения элементов управления (кнопок, вкладок и т.д.). А так посмотрел, что есть Voter, плюс работает через isGranted() - показалось удобным.
Mihai: помощники - это были дешевые фрилансеры, которые нанимались на отдельные, несложные проекты (взять CMS шаблон и немного переделать) и на доработки, но так как фрилансеры брались дешевые, уровень их работ был соответствующие. Из этого получалось, что я всегда доделывал, то, что они там напилили, что влияло на сроки ,как моего заказа, так и того, который я исправлял. Мой товарищ, который занимался продажами, ценник же занижал как на жигули, но при этом говорил заказчикам, что они получат роллсройс. Из-за этого заказчики и требовали и при этом отказывались платить.
Сергей Протько: при наследовании удобно обращаться к свойствам родителя у дочернего класса. нежели так: $child->getParent()->setCommonField1();
либо через такое:
$parent = new Parent();
$parent->setCommonField1();
$child = new Child1();
$child->setParent($parent);
Сергей Протько: просто хорошо бы подошло к oneToOne связям, чтобы постоянно не работать с родительским объектом через сеттер и геттер. Как я понял, это нужно писать свое наследование, грубо говоря.
но ведь Inheritance есть как SingleTable и есть Join. В конечном счете это будут таблицы в БД, вот мне и интересно для каких случаев, какой вариант лучше, хотя бы в общих чертах.
Как вам такая система :
Таблица транзакции (где будет хранится основная информация) :
id
sender_id (null || user)
recepient_id (null || user)
amount (0.00)
created_at (DateTime)
updated_at (DateTime)
active (1 || 0)
---------- для вычисления баланса пользователя достаточно будет сложить суммы где он получатель и отнять, где отправитель
========
И другие таблицы могут расширять основную, т.е. таблица для системных и внешних платежей будет хранить :
id
transaction_id
type (BONUS | POINTS | WEBMONEY)
========
Ели нужно внести оплаты за товар, то можно расширить транзакции таблицей:
id
transaction_id
order_id
========
