Д
А там уже делай что и как хочешь. И не прийдется везде свои методы вызывать.
посмотри как сделан YII2 starter kit (на гитах есть)
и там в админку херачатся все ошибки, замечания и другая тема! Исследуй ее + добавь свой функционал
Size: a a a
2020 June 28
A
спасибо, решил попробовать поэкспериментировать с поведениями, если не получится - попробую твой совет
n
спасибо, решил попробовать поэкспериментировать с поведениями, если не получится - попробую твой совет
напиши как решилв итоге! спасибо
A
А там уже делай что и как хочешь. И не прийдется везде свои методы вызывать.
вот тут не совсем понял, можно яснее?)
Д
вот тут не совсем понял, можно яснее?)
События. Ар кидает события всякие. В том числе после сохранения. Вешаешь на это событие обработчик свой. И в итоге он срабатывает когда что то записалось в базу
A
События. Ар кидает события всякие. В том числе после сохранения. Вешаешь на это событие обработчик свой. И в итоге он срабатывает когда что то записалось в базу
но это же вроде примерно то же самое, что я изначально написал?
Д
но это же вроде примерно то же самое, что я изначально написал?
Нет. Ты предлагал вызывать "свой метод" везде . А обработчик события уии вызовет сам
A
а, понял
Д
Почитай ссылк.
a
может тогда совместить?
Д
Там хоть на все active record вешай хоть на отдельные нужные твои модели.
a
ar лог как технический, если что-то пошло не так - смотреть туда
a
ручной лог - для использования в нормальном режиме
A
Там хоть на все active record вешай хоть на отдельные нужные твои модели.
всё, понял, спасибо
a
сначала добавляешь везде ar логгирование, потом не спеша увешиваешь бизнес логику осмысленными ручными вызовами лога
A
atcq (Алексей)
сначала добавляешь везде ar логгирование, потом не спеша увешиваешь бизнес логику осмысленными ручными вызовами лога
тоже неплохая идея, если руки дойдут то наверное так и сделаю, спасибо
IS
Коллеги, а дайте совет, как правильно реализовать архитектуру взаимодействия с внешним API.
Задача: есть внешняя 1С, с ней идёт взаимодействие с совершенно разными целями. На примере интернет-магазина - передать данные о новом заказе; завести нового клиента, получить реквизиты нового клиента и так далее. Исторически часть обмена идёт через SOAP, часть уже через HTTP JSON.
Есть две мысли:
1. Реализовать класс API и его методами отправлять-получать данные.
2. Реализовать кроме класса API ещё классы Request и Response для обмена и передавать их методам класса API.
типа $api->send(UserCreate\Request $request)
Задача: есть внешняя 1С, с ней идёт взаимодействие с совершенно разными целями. На примере интернет-магазина - передать данные о новом заказе; завести нового клиента, получить реквизиты нового клиента и так далее. Исторически часть обмена идёт через SOAP, часть уже через HTTP JSON.
Есть две мысли:
1. Реализовать класс API и его методами отправлять-получать данные.
2. Реализовать кроме класса API ещё классы Request и Response для обмена и передавать их методам класса API.
типа $api->send(UserCreate\Request $request)
IS
В первом варианте не нравится громоздкость получающихся интерфейсов, во втором - сложность: завели юзера, из юзера как-то должен получиться UserCreateRequest который по сути DTO, потом его надо передать, получить Response, разобрать где-то и обработать и куда-то сложить, боюсь запутаться.
С
В первом варианте не нравится громоздкость получающихся интерфейсов, во втором - сложность: завели юзера, из юзера как-то должен получиться UserCreateRequest который по сути DTO, потом его надо передать, получить Response, разобрать где-то и обработать и куда-то сложить, боюсь запутаться.
глаза боятся, руки делают