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

это же не модель

Это компонент

Врапер над telegram-bot-api!))

почему это должно быть компонентом ?

его придется в конфиге подрубать

а я хотел по типу инклюда

где надо там и подрубил

extends Object, тебе события не нужны, легче будет, и да, подрубил в конфиге и потом дернул где нужно и publish()

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

т.е. любой класс который ты захотел сделать не связанный с сайтом надо делать его компонентом?

а папку components в common или frontend ?

Компонент - это базовый класс, который реализует свойства, события и поведение. Блин ( мне кажется мой класс по отправке сообщения в телеграмм не является событием и поведением

Где угодно, главное чтобы тебя было удобно, если используется и со стороны фронта и на беке, то коммон, если где-то в одной части, то в ней соответственно ... да, такие вот не связанные компоненты повышают реюзабильность кода ... я например инклуды исп только для разбиения конфига на составные части для удобства, чтобы большим не был, например db redis rabbit и тд...

Компонент - это базовый класс, который реализует свойства, события и поведение. Блин ( мне кажется мой класс по отправке сообщения в телеграмм не является событием и поведением

Я же тебе писал, отнаследуйся от yii\base\Object это не помешает ему быть облегченным компонентом ... !)))

где надо там и подрубил

Подключение компонента в конфиге еще не значит, что он будет загружен. Только при первом обращении. А это и есть "где надо, там и подрубил", только с центральным конфигом

yii\base\Object - я так не пробовал еще))

Попробуй!)))

ого как много у него Subclasses

это чо один из первоначальных классов ? Объект

Привет всем, кто не спит. Столкнулся с неожиданной проблемой. Мне нужно перенести мои пхп классы из папки models в папку forms. Но почему-то когда перемещаю, он автоматом не исправляет пути. А если я это начинаю делать сам, то он попросту не видит app\models\forms. ЧЯДНТ? Гугол, зараза, молчит.

Сорян, в подпапку forms папки models.

Я не много не понял после того как я передаю параметры get что с ними делать на сервере или я что то не так сделал ?

Ничего не делать. Пагинатор должен подхватить из строки запроса параметр страницы сам

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

LOL

Анек за неуловимого Джо уже скидывали?

помогло?

помогло. спасибо

Привет всем, кто не спит. Столкнулся с неожиданной проблемой. Мне нужно перенести мои пхп классы из папки models в папку forms. Но почему-то когда перемещаю, он автоматом не исправляет пути. А если я это начинаю делать сам, то он попросту не видит app\models\forms. ЧЯДНТ? Гугол, зараза, молчит.

Неймспейс?

вы пользуетесь ? : yii\behaviors\SluggableBehavior

Да

Только там боль с транситерацией из коробки, надо тюнить.

почему боль, оно же вроде специально и заточено под это дело

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

Доброе утро! Почитал немного про DDD... интересно, сложно, много дискуссионных моментов :) Хочу постепенно внедрить в проект, если я правильно понял, сервисный слой. Вижу это так: 1) Оставляем AR-модель. 2) Добавлю в приложении папку services, где будут т. н. сервисы (например, EmployeeService), в нем будут описаны все действия которые можно сделать с AR-моделью. 3) В контролере экшены будут выглядить примерно так: … Получение сущности и проверка доступа … try { $entityService->anythingDo(); } catch (\Exception $e) { … Обработка исключений … } … Вывод … Покритикуйте. Облегчит ли такой подход разработку с ростом проекта или я не вижу каких-то подводных камней, которые наоборот появятся и усложнят всё? Сейчас я действия с сущностями, которые используются в нескольких местах, тупо выношу в хелперы и вызываю... И вот от этого хочется избавиться.

Доброе утро! Почитал немного про DDD... интересно, сложно, много дискуссионных моментов :) Хочу постепенно внедрить в проект, если я правильно понял, сервисный слой. Вижу это так: 1) Оставляем AR-модель. 2) Добавлю в приложении папку services, где будут т. н. сервисы (например, EmployeeService), в нем будут описаны все действия которые можно сделать с AR-моделью. 3) В контролере экшены будут выглядить примерно так: … Получение сущности и проверка доступа … try { $entityService->anythingDo(); } catch (\Exception $e) { … Обработка исключений … } … Вывод … Покритикуйте. Облегчит ли такой подход разработку с ростом проекта или я не вижу каких-то подводных камней, которые наоборот появятся и усложнят всё? Сейчас я действия с сущностями, которые используются в нескольких местах, тупо выношу в хелперы и вызываю... И вот от этого хочется избавиться.

Насколько я помню, вроде бы вызывается сервисный слой, а не работа с сущностью напрямую

Насколько я помню, вроде бы вызывается сервисный слой, а не работа с сущностью напрямую

Да, верно, так и задумывал, опечатался :)

И сущность кидай в сервис)

Лично у меня сейчас в проектах что-то вроде public function actionRegister() { $form = new RegisterForm; $form->setAttributes(Yii::$app->request->bodyParams); if ($form->validate()) { return Yii::$app->userService->register($form); } return $form; }

Это REST

И сущность кидай в сервис)

Да, такое и хочу делать, Идея на вид простая. Берём классический Controller + AR. И делаем Controller + Service + AR. Controller создаёт AR-томдель, проверяет доступы и отдаёт в сервис, сервис уже выполняет все действия и если есть проблемы - вываливает исключение.

Но может что-то упускаю и не всё так просто :)

В самом просто варианте - да, приблизительно так

Вместо Yii::$app->userService можно внедрять зависимостью в контроллер и писать $this->userService

Вместо Yii::$app->userService можно внедрять зависимостью в контроллер и писать $this->userService

Делал так раньше, не понравилось)

На вкус и цвет

Вместо Yii::$app->userService можно внедрять зависимостью в контроллер и писать $this->userService

Зато теперь конструктор не нужно везде объявлять

А если через статический метод модели? Employee::getService() ?

@d_naumenko пользуясь случаем вопрос такой: где удобнее проверять на права доступа? В сервисном слое или в контроллере? Или может быть вообще в форме при валидации?)

А если через статический метод модели? Employee::getService() ?

Кажется будут проблемы с тестированием

А если через статический метод модели? Employee::getService() ?

Да, во-первых тестирование, во-вторых не в ту сторону зависимости смотрят

Кажется будут проблемы с тестированием

Возможно... с тестами пока не работал :(

Делал так раньше, не понравилось)

А как сервис попадает сюда: Yii::$app->userService ?

@d_naumenko пользуясь случаем вопрос такой: где удобнее проверять на права доступа? В сервисном слое или в контроллере? Или может быть вообще в форме при валидации?)

Ясное дело что опять же на вкус и цвет, но я пока не нашел удобного варианта

А как сервис попадает сюда: Yii::$app->userService ?

Тебе в документацию http://www.yiiframework.com/doc-2.0/guide-structure-application-components.html

Тебе в документацию http://www.yiiframework.com/doc-2.0/guide-structure-application-components.html

Понял, спасибо :)

@d_naumenko пользуясь случаем вопрос такой: где удобнее проверять на права доступа? В сервисном слое или в контроллере? Или может быть вообще в форме при валидации?)

Смотря какие права :) Есть понятие "инварианты" - это валидация бизнес-правил вроде "нельзя создать Employee, если его ИНН уже принадлежит другому Employee". Такое в контроллере не проверишь, это идет в сервисный слой. А есть права доступа к операциям CRUD, реализующиеся через RBAC. Например "создать employee может только пользователь с permission=employee.create". Такое условие как раз хорошо описывается фильтрами в контроллере. Кроме того, бывают комплексные операции, вроде "импорт сотрудников из файла экспорта 1С", и там permission другой: "employee.import-from-1c". Заметь, что операция импорта - это парсинг + foreach(create), а пермишн - другой. Проверяя это в контроллере, проблем не будет. А если вынести такую проверку в сервис - придётся как-то костылять, чтобы обработать импорт. Уловил? :)

есть ли готовое решение магазина на yii2, кто что может посоветовать?

Смотря какие права :) Есть понятие "инварианты" - это валидация бизнес-правил вроде "нельзя создать Employee, если его ИНН уже принадлежит другому Employee". Такое в контроллере не проверишь, это идет в сервисный слой. А есть права доступа к операциям CRUD, реализующиеся через RBAC. Например "создать employee может только пользователь с permission=employee.create". Такое условие как раз хорошо описывается фильтрами в контроллере. Кроме того, бывают комплексные операции, вроде "импорт сотрудников из файла экспорта 1С", и там permission другой: "employee.import-from-1c". Заметь, что операция импорта - это парсинг + foreach(create), а пермишн - другой. Проверяя это в контроллере, проблем не будет. А если вынести такую проверку в сервис - придётся как-то костылять, чтобы обработать импорт. Уловил? :)

Спасибо за развернутый ответ (: Только вот последнее туговато дошло

Спасибо за развернутый ответ (: Только вот последнее туговато дошло

У тебя есть операция "Импорт пользователей", которая по сути является операцией "Создание пользователя" в цикле. Но право импорта и право создания - разные права

Т.е. все-таки лучше постараться все проверки делать в фильтрах/контроллере? А в сервисном слове можно проверить только для целостности?

Можно иметь право импортировать, но не иметь права создавать и наоборот.

У тебя есть операция "Импорт пользователей", которая по сути является операцией "Создание пользователя" в цикле. Но право импорта и право создания - разные права

Да, уловил)) Просто дольше времени ушло, чем на первые два

Т.е. все-таки лучше постараться все проверки делать в фильтрах/контроллере? А в сервисном слове можно проверить только для целостности?

Что значит "ВСЕ"?

Что значит "ВСЕ"?

Права и правила на совершение действия

Что значит "ВСЕ"?

Сейчас у меня все в длиннющих методах behavoirs : [ 'allow' => true, 'actions' => ['update'], 'roles' => ['updatePost'], 'roleParams' => ['postId' => Yii::$app->request->get('id')]; ], А внутри сервиса простая проверка по требованиям бизнес логики, где выкидывается Exception в случае ошибки.

ERROR: S client not available

@d_naumenko Просто может быть есть что-то, что избавляет нас от метода behaviors на три экрана скролла?

@d_naumenko Просто может быть есть что-то, что избавляет нас от метода behaviors на три экрана скролла?

В поведениях не понравилось, легко забыть там что-то добавить/убрать. Делаю у себя проверку внутри экшенов: // Проверка доступа if (!Yii::$app->user->can('projectParamsEdit', ['project' => $project])) { throw new ForbiddenHttpException(); } Так и не придумал ничего умнее))

оберни в функцию помощник ensureAllow...

оберни в функцию помощник ensureAllow...

Как это поможет?

не будет ифов лишних по всем экшенам, и в будущем легко отрефакторить

не будет ифов лишних по всем экшенам, и в будущем легко отрефакторить

Спасибо, буду использовать. Вообще вот это думаю внедрить в проект: https://github.com/samdark/yii2-cookbook/blob/master/book/structure-global-functions.md

да, это туда и ляжет

ничего страшного в глобальных функциях нету, ускоряет разработку, если проект закрытый (не open source) - стоит однозначно использовать

еще плюс - автокомплит для кастомных компонентов, если ты не хочешь переопределять Yii класс (чтобы описывать компоненты через phpdoc), но хочешь автокомплит своих компонентов - кидаешь их в глобалы

какой то страшный набор костылей, удобный только их автору

что страшного?

А зачем это?

Может проще автокомплит IDE настроить и не париться?

как настроить автокомплит, если IDE не знает о кастомных компонентах?

А зачем это?

Может проще автокомплит IDE настроить и не париться?

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

два варианта - переопределить Yii класс, и в phpdoc описывать компоненты, или использовать шорткаты

все верно

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

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

а кто мешает хелперы просто юзать?

а чем это не хелперы?

а кто мешает хелперы просто юзать?

какой то страшный набор костылей, удобный только их автору

illuminate/support в 100500 проектах

хотя функции там банальные

аргументов от Павла и Владислава не услышал - возвращаюсь к работе

Ну например тем что не явно где они лежат и идеально будет работать автокомплит

if (!Yii::$app->user->can('projectParamsEdit', ['project' => $project])) { throw new ForbiddenHttpException(); } vs use ххх/xxx/AccessHelper; AccessHelper::can('projectParamsEdit', ['project' => $project]); vs can('projectParamsEdit', ['project' => $project]);