думаете basic норм?

просто сам юзаю свой шаблон, но навязывать не хочу

думаю как минимум advanced удобней )

если уж расширять кругозор то с этого )

Хорошо, резонно, соглашусь

потому что регулярные выражения :)

А как это обойти?

<action> - не значит экшен

<action:\w+> например

Не помогло :(

Не помогло :(

http://www.yiiframework.com/doc-2.0/guide-runtime-routing.html#url-rules читайте до просветления :)

А готового решения нигде нету?

@sizepermru вы были очень сильно правы

@Vaderoff вы документацию пробовали читать?

Нет (

Так, пожалуйста, сделайте нам и себе такую услугу

ААААААААААААААААААААаааааааааааааааааааааааааааааааааааааааррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррррр!!!!!!!1111111111235

Бизнес-логика размазанная по куче контроллеров это жопа.

Так, пожалуйста, сделайте нам и себе такую услугу

Можешь конкретно сказать из-за чего это?

Можешь конкретно сказать из-за чего это?

Я ссылку дал на два абзаца текста. Там все описано

Просто прочитай.

То есть мне нужно поместить это все в одну строку?

Ты программист или экстрасенс? :)

Похоже не помогло, давай так: Напишите, что именно вам надо

агрх, мне в школе учебники читать, так еще и дома доки к фреймворкам ((

Так вы сударь лентяй)

Так вы сударь лентяй)

Да вы правы. Но стараюсь не быть им. Ибо лентяй никогда не победит, а победитель не может быть лентяем.

Совсем какие-то простые вопросы спрашиваешь. Это ведь всё в доках есть.

Больше не буду смотреть на ютубе уроки (

Такая тема: Есть юзеры. Есть "пакеты" (по аналогии с "пакетами минут и смс" т.е. цена, скидка, продолжительность действия и всякие там дополнительные плюшки). Есть заказы (включает в себя список товаров и услуг). Есть платежи (включают в себя пакеты, заказы, способ/статус оплаты и т.п.). Логика с которой пакет присваивается юзеру довольно замороченная, плюс имеет свойство меняться. Примерный сценарий такой: Юзер покупает подписку, при этом либо оплачивает её, либо обещает оплатить наличными/картой курьеру. В первом случае она сразу добавляется юзеру (либо продлевает срок действия текущей). Во втором не происходит вообще ничего до того момента, когда платёж заапрувит админ. Далее она уже влияет на цены (даёт скидку), начисляет что-то на лицевой счёт (с него можно оплачивать всякое), да и много ещё на что влияет. Кроме того, почти уверен, что когда-нибудь обязательно будет решено сделать возможность иметь несколько подписок одному юзеру и всячески извращаться с логикой их применения / добавления / активации. При этом сейчас имеющаяся логика кое-как размазана по экшнам контроллеров и очень туго поддаётся чтению и правке. Очевидно надо эту логику как-то в одно место собрать, да желательно отдельно от всякого там хранения/валидации. Но вот как лучше это сделать? [удалена куча рассуждений на тему разных решений и их недостатков]

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

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

Такая тема: Есть юзеры. Есть "пакеты" (по аналогии с "пакетами минут и смс" т.е. цена, скидка, продолжительность действия и всякие там дополнительные плюшки). Есть заказы (включает в себя список товаров и услуг). Есть платежи (включают в себя пакеты, заказы, способ/статус оплаты и т.п.). Логика с которой пакет присваивается юзеру довольно замороченная, плюс имеет свойство меняться. Примерный сценарий такой: Юзер покупает подписку, при этом либо оплачивает её, либо обещает оплатить наличными/картой курьеру. В первом случае она сразу добавляется юзеру (либо продлевает срок действия текущей). Во втором не происходит вообще ничего до того момента, когда платёж заапрувит админ. Далее она уже влияет на цены (даёт скидку), начисляет что-то на лицевой счёт (с него можно оплачивать всякое), да и много ещё на что влияет. Кроме того, почти уверен, что когда-нибудь обязательно будет решено сделать возможность иметь несколько подписок одному юзеру и всячески извращаться с логикой их применения / добавления / активации. При этом сейчас имеющаяся логика кое-как размазана по экшнам контроллеров и очень туго поддаётся чтению и правке. Очевидно надо эту логику как-то в одно место собрать, да желательно отдельно от всякого там хранения/валидации. Но вот как лучше это сделать? [удалена куча рассуждений на тему разных решений и их недостатков]

бандлы )

вообще сервисный слой упрощает работу

Со вторым вариантом немного не понятно, как, например, называть классы этих моделей. Ну допустим вот эта история с платежом, юзером, подпиской и опциональным админом. Что это? Платёж, юзер, подписка? Не ясно. А раз не ясно можно и божественный класс запилить.

это прослойка между контроллером и AR в прямом его понимании или моделью

тут подробней ответил slavcodev http://www.yiiframework.ru/forum/viewtopic.php?p=193207#p193207

Для более точного понимания Фаулер "Архитектура корпоративных приложений"

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

да может оно и не надо

Хм. То есть получается, я создаю, скажем, класс ServicePackBuy , в нём, скажем, два метода: userMakePayment(User $user, Payment $payment) и adminConfirmedUserPayment(User $user, Payment $payment) Или... Один метод: go(Payment $payment) в котором что-то типа if($payment->status === Payment::STATUS_CONFIRMED) { $user->pack = $pack; .... } Правильно я понял идею?

агрх, мне в школе учебники читать, так еще и дома доки к фреймворкам ((

Когда я в школе учился, то доки были в приоритете над учебниками

Хм. То есть получается, я создаю, скажем, класс ServicePackBuy , в нём, скажем, два метода: userMakePayment(User $user, Payment $payment) и adminConfirmedUserPayment(User $user, Payment $payment) Или... Один метод: go(Payment $payment) в котором что-то типа if($payment->status === Payment::STATUS_CONFIRMED) { $user->pack = $pack; .... } Правильно я понял идею?

ну if поменьше желательно

если надо Payment::STATUS_CONFIRMED то вешаем события на PaymentInterface

Хотя, блин. Наверное этот BuyPackService Должен побольше методов иметь. На заказ пакета, на его оплату, на подтверждение/отмену админом. Или нет? * Это чтобы можно было легко и просто менять всю эту логику, изменяя только этот класс и ничего более

если надо Payment::STATUS_CONFIRMED то вешаем события на PaymentInterface

Не понял.

Мне кажется, что подписка может иметь статус активна или нет Если пользователь платит сразу - сразу активируем, если нет - админ активирует

Ну и, соответственно, в тех местах, где нужно проверять, есть подписка или нет, проверять, активна ли она

Мне кажется, что подписка может иметь статус активна или нет Если пользователь платит сразу - сразу активируем, если нет - админ активирует

Ну тут же тоже самое. Только вместо присвоения подписки юзеру присвоение статуса подписке (ага, появляется ещё одна модель, связующая юзера, подписку и статус)

Проблема в том, что это надо придётся делать в _разных_ местах. И эта логика любит меняться.

Оно ведь сейчас так и есть: в одном контроллере что-то выставилось, в других что-то проверяется

Можно, конечно, из говна и палок сделать ракету, но качество будет, сами понимаете, не айс Если там всё так плохо, то лучше переделать

а когда надо что-то менять приходится по всем экшнам всех контроллеров лазить

ну вот я и выясняю как бы переделать

чтобы не сделать из говна говно

Ну смотрите Добавлять, активировать - думаю, понятно как Добавлять на счет при активации - через события Проверять - расширяем юзера методом getSubscriptions(), который должен возвращать только активные подписки Ну и, если мы говорим об изменении цены, то в модели товара (например) делаем getPrice(), который проверяет подписку у пользователя, и возвращает цену с учетом скидки подписки

@Ivan_0x9d8e я бы сделал компонент, который бы заведовал всей сложной логикой транзакций, оплат и тд и покрыл бы его тестами Компонент бы рабол с интерфейсами, которые модели бы реализировали

Надеюсь, не очень сумбурно написал

Не понял.

сервис оплаты кидает событие (класс от Event). передаем в событие все что надо событие имплементирует интерфейс вешаем на интерефейс слушателей

Поддерживать это не очень сложно, если тесты держать в порядке

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

ERROR: S client not available

Если делать на event-ах, будет нормальный IoC, но сложнее поддержка

Ну смотрите Добавлять, активировать - думаю, понятно как Добавлять на счет при активации - через события Проверять - расширяем юзера методом getSubscriptions(), который должен возвращать только активные подписки Ну и, если мы говорим об изменении цены, то в модели товара (например) делаем getPrice(), который проверяет подписку у пользователя, и возвращает цену с учетом скидки подписки

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

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

Не очень понимаю зачем тут события

Чем вызов метода не событие?

Вы слышали об Inversion of control?

Неа

Если нет, тогда лучше делайте один компонент

И там вся логика

Тесты написать будет просто

Главное делать все в одном месте

Как я понял, это для вас важно

Важно то важно, но и отсутствие божественных классов тоже важно

Тут одно с двух

Думаю, если у вас будет нормально покрыт тестами один мега-класс - - будет вменяемо

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

Лучше на все

Но это лично моё мнение

Если уже хотите держать все в одном месте

Лучше на все

Как-то так, пожалуй, и сделаю

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

проще выбрать когда класс готов

те. пишем класс и рефакторим

когда есть опыт рефакторинга меньше становится

а может и больше )))

Рефакторинг - это?

Рефакторинг - это?

Строго изменение кода, без изменения его внешнего поведения. А так просто работа над его структурой и порядком.

рефакторинд в пхпшторме ничо не делает

я думал он мне код расставит красиво

а он тупо пробелы убрал и всё

?