В ожидании Yii2 2.0.4

Как вы наверное догадались, хочу рассказать о Yii2 и о том, что ждет новичков в стартапе, который выбрал данный фреймворк. Ни для кого не секрет, что многие фреймворки используют компоненты symfony, дабы не изобретать новый велосипед. Многие, но не Yii, но при этом Yii многое позаимствовал от symfony и впитал в себя лучшее от Ruby on Rails. На github в issues часто можно увидеть предложение по расширению функционала, перенятого у этих фреймворков. В данной статье хотелось бы описать именно те моменты, в которых разработчики Yii не сходятся во мнении с разработчиками других фреймворков.

ActiveRecord


AR — это модель, представляющая собой 1 запись в хранилище, но мало кто знает, что в Yii так же finder прячется за статическим методов find и называется он ActiveQuery.

ActiveQuery


Рассмотрим пример User::find()->andWhere(['username' => 'ok'])->one().

На первый взгляд все логично, не считая того факта, что в коробке в advanced template используется User::findByUsername('ok'). Но если в первом случае мы сможем отвязаться от класса User, передав, к примеру, в конструктор $query = User::find()->andWhere(/*чтотоеще*/), то в «коробочном» варианте вам чтобы добавить условие нужно расширить класс User и перекрыть логику работы в методе findByUsername.

Стоит отметить, что ActiveQuery завязан на класс модели, и если вы хотите добавить default scope, то вам необходимо расшириться от модели и перекрыть вышеупомянутый метод find:

public static function find()
{
    return parent::find()->andWhere(['status' => 'active']);
}

Чтобы наложить условие по умолчанию на ActiveQuery, нам нужно расширить ActiveRecord.

Rules или валидация


В гайде по Ruby on Rails на этот счет написано следующее:

1.1 Why Use Validations?

Validations are used to ensure that only valid data is saved into your database.

yiisoft/core-developers так не думают, и считают, что валидировать нужно только входящие данные от пользователя в форме, а все остальное — это проблема в руках программиста, т.е. вы должны сами отлавливать pdo exception, если уж вдруг что-то пошло не так — ошибок валидации не ждите. Поэтому в коробке минимально проверяют данные перед записью в бд. Быть может, это связано с экономией на производительности:
— все валидаторы создаются сразу при инициализации модели, не зависимо от сценария;
рендер input type=text (на спичках).

Кстати говоря, о производительности. Тесты, размещенные в интернете, были произведены при минимальном кол-ве кода Yii, то есть сейчас картинка явно будет отличаться в худшую сторону.

Безопасность или производительность — каждый решает сам. В коробке advanced app — производительность.

Но даже выбрав безопасность, вы можете смело забывать про «коробочные поведения для атрибутов», которые завязаны на события beforeInsert и beforeUpdate, а события beforeValidate всего лишь одно, или необходимо модернизировать value свойство с проверкой $event->sender->isNewRecord.

Так же выбрав безопасность следует забыть про метод link, который должен связывать 2 модели между собой по foreign key. Связано это с тем, что метод link сохраняет модель после «перелиновки» и это поведение неизбежно, причем сохранение идет без валидации, следовательно вышеупомянутые поведения для атрибутов отработаны не будут и мы получим исключение pdo о том, что поле обязательно к заполнению. Валидировать до метода link мы не можем, так как для foreign keys существует валидатор exist, который провалится, или мы должны делать выборочную валидацию, причем необходимо передавать белый список атрибутов, и при добавлении нового атрибута в модель будьте готовы перелопатить кучу кода.

Безопасность или плюшки из коробки — решать вам.

ActiveRelation


Здесь речь пойдет о связи моделей между собой или понятие модуля в Yii.
Как известно — модуль — самодостаточная единица приложения. Рассмотрим пример: подключив 2 модуля User и BankAccount, мы должны связать между собой модели User и UserAccount. Это я оставлю вам как домашнее задание, так как разработчики сами пока не могут дать на это ответ. Именно поэтому мне кажется, User и Rbac в коробке yii, а не в виде расширений. А пока посмотрим на то, что придумано давно symfony.

Тем, кто всерьез решит сделать «домашку», надо учесть, что модели невозможно конфигурировать по ряду причин, одной из них является создание модели, как связанной по ключу.

Если вы решили «домашку», попробуйте решить ее снова, но не перекрывая обе модели из модулей.

Скажем дружно, модулям — ненужно.

На этом статью будем считать оконченной. В довесок ниже будет еще несколько бонусов, но для начала хочу сказать, что я разрабатываю на данном фреймворке более 5 лет (начинал еще с yii 1.x) и мне он нравится своей возможностью конфигурирования компонентов, но в yii2 все больше и больше завязывается на Closure, что не позволяет уже так гибко конфигурировать, как хотелось бы. Возможно, связано это с тем, что в сообществе много фанатов Laravel? Так же хотелось бы поблагодарить разработчиков yii2 за их вклад и труд, первый блин всегда комом, второй уже получше.

Бонусы


— Во всех языках программирования при вызове события в него можно передать параметры, в Yii параметры надо передавать при вешании обработчика;
— Бывает и Вика учит «быдлокодить»;
— Мистика алиасов (https://github.com/yiisoft/yii2/blob/master/framework/helpers/BaseFileHelper.php#L135).

Любите Yii, помогайте сообществу. Если ваш issue сразу завернули — не расстраивайтесь. Возможно, кто-то позже создаст аналогичное и его не завернут (были и такие случаи). Всем чистого кода, понятных комментариев в нем и отсутствие ошибок в тестах.

P.S. Знаю, что некоторые из разработчиков yii посещают данный ресурс, хотелось бы извиниться перед ними. Возможно, я где то наврал — буду рад любым комментариям ниже.

UPD: Предложенный вариант zelenin habrahabr.ru/post/254179/#comment_8348781 имеет право на жизнь и даже вполне себе рабочий, как по мне это странное поведение контейнера di. Но благодаря этому поведению я думаю получится подружить 2 модели из разных модулей — позже отпишусь о результатах.
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 83

    0
    Не использовал на полную yii, но пишу на похожем

    Чтобы наложить условие по умолчанию на ActiveQuery, нам нужно расширить ActiveRecord.
    public static function find()
    {
        return parent::find()->andWhere(['status' => 'active']);
    }
    

    Не люблю такое, лучше уж отдельный метод сделать и его использовать, а то будет обязательное такое место, где не надо ['status' => 'active'] и тогда полная путаница начнется. Не говоря уже о том, что привыкаешь к тому что такие методы как find работают прозрачно и надо самому правильно составить запрос, без всяких значений по-умолчанию

    User::findByUsername('ok')
    Не знаю как yii, у меня примерно так:
    User::findByUsername('ok', ['status' => 'active'])
    вторым аргументом можно уточнить условие выборки

      0
      но имхо лучше не делать так, как в advanced template, а вынести это в виду скоупов. Если уж finder у нас в модели в виде объекта ActiveQuery, то и различные алиасы типа findByUsername надо вынести в него — этому не место в модели.
        0
        согласен, в своих проектах делаю скоуп byUsername, а точнее byLogin, т.к. в качестве логина может выступать не только username, но и email
          0
          Простите, немного запутался. А для чего другим моделям нужен будет явный метод findByUsername, конечно при условии что все модели наследуют новый класс ActiveQuery? Подобные методы обычно создаются через магические методы __call и __callStatic, поэтому я думал что лучше просто переопределить, в данном случаи __callStatic, и научить его использовать второй аргумент как уточняющий условие выборки. Реальных методов вроде User::findByUsername не будет у моделей.
          В целом я исхожу от общей практики yii к статическим помощникам, поэтому такие вещи и оказываются в модели. Извиняюсь, если неправильно понял, я лишь свое мнение написал про пост, yii не так хорошо знаю
            0
            findByUsername вообще не место где-либо — habrahabr.ru/post/254179/#comment_8348499 такой подход правильнее
              0
              в Yii «статические помощники» находятся в модели, т.к. ActiveQuery завязан на класс модели, это можно увидеть в методе find — при построении квери в него передается класс модели.
            0
            Много способов реализации, я хотел подчеркнуть то, что ради добавления условия выборки мы расширям модель, а именно эту ненужную связь — это 2 разные сущности, но при расширении query надо перекрывать обе
              +2
              вы почему-то считаете, что вам надо перекрывать метод из adavnced template. Это не то, что вы называете «коробкой». Это кем-то написанный код для примера, который, уверен, при создании issue с объяснением, будет вынесен в UserQuery.
              Не надо тащить к себе в проект код из примера — делайте свой.

              Вообще часто пишут «в yii2», имея в виду templates. Но это всего лишь примеры организации кода.
                0
                код написан не кем то, а разработчиками, и большинство программистов берут за основу практики из него
                  +1
                  ради бога) но в документации написано, что класс user должен реализовывать IdentityInterface, а не браться из template. А вы конечно можете брать, что угодно, но как минимум это к фреймворку не относится.

                  Если бы «разработчик фреймворка» означало разработчика безгрешного и пишущего правильно, то у нас был бы один хороший фреймворк, а не несколько.

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

                  Посмотри пример и сделай правильно. Фреймворк ты не можешь исправить (можешь конечно), а сделать правильно приложение — да, не исправляя чужие ошибки или несуразности, а не внося их в проект.
                    0
                    ради бога) но в документации написано, что класс user должен реализовывать IdentityInterface

                    На сколько мне известно, отвязку от интерфейса убрали в фреймворке давно, сейчас имплементация данного интерфеса лишь условность.
                    Странность в этом интерфейсе все равно — остается — он только для рест приложений? или это нормально кидать исключения при реализации методов интерфейса? может этому место в rest/models, а не в common/models?

                    Эта статья была создана не с целью «обгадить фреймворк», не надо во мне видеть врага
                      0
                      или это нормально кидать исключения при реализации методов интерфейса?

                      Вставлю свои пять копеек.
                      Вы даёте ссылку на демо-шаблон приложения, в котором не реализован некий метод интерфейса IdentityInterface.
                      Каковы в данном случае претензии к фреймворку?
                      Да и к демо-шаблону нет претензий в данном случае. Ну не реализован там этот метод, да. Что (и главное ЗАЧЕМ) вы предлагаете там вставить? die('error'); что ли? или return null;? Какое-то копание в ненужных деталях получается.

                      Статью, кстати, плюсанул. Люблю такие темы. Обычно много нового узнаёшь по ходу чтения комментариев.
                        0
                        Зачем имплементировать интерфейс, если он необязателен, тогда и не было бы данного метода. Я не предъявляю претензий, я лишь озвучиваю свое мнение, и ради дискуссий, самообразования и других мнений запостил данную статью
                          0
                          ну как необязателен? github.com/yiisoft/yii2/blob/master/framework/web/IdentityInterface.php#L49 посмотрите код — эти методы используются кодом фреймворка для своих внутренних целей, поэтому должны быть имплементированы.
                        +2
                        вы — автор статьи — сильно плаваете в теме, делая необоснованные предположения.
                        Я не вижу в вас врага и прекрасно понимаю, что yii2 — не самое лучшее творение человека, но практически все ваши утверждения необоснованы.
                          –1
                          Я опровергнул множество ваших коментариев, а это говорит о том, что судить о том как я плаваю — явно не вам — вы тогда тонете
                            +1
                            например? Что вы опровергли? Я вам пишу факты, вы отвечаете: не уверен, не думаю, что это будет работать итд.
                            Все, что я пишу из фактического — проверено.
                              –2
                              я заметил как вы тестируете код перед выкладкой в паблик
                              поэтому не удивлюсь что с di это лишь ваши догадки
                                +3
                                это уже явно направленное против меня замечание, т.к. касается оно опечатки в ТЕКСТЕ из примера использования виджета — это не код, а текст в демо.
                                Обсуждайте свою статью — не надо искать косяков в других местах, не надо доказывать, что вы лучше меня знаете yii. Я вам предлагаю факты — вы можете их опровергнуть другими фактами. То, что делаете вы, как минимум некрасиво.
              0
              начнем с того, что advanced template — это не «из коробки», а пример реализации структуры приложения.

              >> На первый взгляд все логично, не считая того факта, что в коробке в advanced template используется User::findByUsername('ok'). Но если в первом случае мы сможем отвязаться от класса User, передав, к примеру, в конструктор $query = User::find()->andWhere(/*чтотоеще*/), то в «коробочном» варианте вам чтобы добавить условие нужно расширить класс User и перекрыть логику работы в методе findByUsername.

              ничего не нужно перекрывать. Можно использовать любые варианты.

              >>yiisoft/core-developers так не думают, и считают, что валидировать нужно только входящие данные от пользователя в форме, а все остальное — это проблема в руках программиста, т.е. вы должны сами отлавливать pdo exception, если уж вдруг что-то пошло не так — ошибок валидации не ждите. Поэтому в коробке минимально проверяют данные перед записью в бд. Быть может, это связано с экономией на производительности:

              в advanced template нет функционала сохранения юзера в базу, соответственно и валидация такая не нужна.

              >>Так же выбрав безопасность следует забыть про метод link, который должен связывать 2 модели между собой по foreign key. Связано это с тем, что метод link сохраняет модель после «перелиновки» и это поведение неизбежно, причем сохранение идет без валидации, следовательно вышеупомянутые поведения для атрибутов отработаны не будут и мы получим исключение pdo о том, что поле обязательно к заполнению.

              link линкует УЖЕ сохраненную в БД модель, меняя только foreign key (https://github.com/yiisoft/yii2/blob/master/framework/db/BaseActiveRecord.php#L1197). Соответственно у вас уже валидация была пройдена до этого и повторно ее проводить не нужно.

              >>Как известно — модуль — самодостаточная единица приложения. Рассмотрим пример: подключив 2 модуля User и BankAccount, мы должны связать между собой модели User и UserAccount.

              di без проблем делает вам что угодно

              >> P.S. Знаю, что некоторые из разработчиков yii посещают данный ресурс, хотелось бы извиниться перед ними. Возможно, я где то наврал — буду рад любым комментариям ниже.

              я опроверг все ваши основные тезисы. Собственно чего-то действительно правдивого я тут и не заметил.

              Рад буду дискуссии.
                0
                ничего не нужно перекрывать. Можно использовать любые варианты.

                Начну с того, что в common модели накладывать скоуп на status это не правильно, вот если бы на frontend модели — согласен.
                перекрывать в любом случаем придется модель, ради своего ActiveQuery или добавления скоупов прямо в модель. Т.е. модель задевается всегда, даже когда, казалось бы это ее не должно касаться.

                в advanced template нет функционала сохранения юзера в базу, соответственно и валидация такая не нужна.

                github.com/yiisoft/yii2-app-advanced/blob/master/frontend/models/SignupForm.php#L51

                link линкует УЖЕ сохраненную в БД модель, меняя только foreign key (https://github.com/yiisoft/yii2/blob/master/framework/db/BaseActiveRecord.php#L1197). Соответственно у вас уже валидация была пройдена до этого и повторно ее проводить не нужно.

                спорно github.com/yiisoft/yii2/blob/master/framework/db/BaseActiveRecord.php#L1198 и зачем делать линовку, для модели которая уже сохранена? так же уже должны быть проставлены ключи

                di без проблем делает вам что угодно

                Без примера кода не поверю, что связь будет именно на ту модель которая мне нужна. Я верю что можно создать модель с аналогичным неймспейсом и в контейнере (точнее в classmap) указать, чтобы пользовалась она. Но нам надо модель переписать всю с нуля, т.к. расшириться мы от нее не сможем (неймспейс мы переопределили)

                я опроверг все ваши основные тезисы. Собственно чего-то действительно правдивого я тут и не заметил.

                пока не заметил
                  0
                  >>Начну с того, что в common модели накладывать скоуп на status это не правильно,
                  я про скоуп и findByUsername (обсудили выше)

                  >>github.com/yiisoft/yii2-app-advanced/blob/master/frontend/models/SignupForm.php#L51
                  там есть валидация от формы регистрации. Еще раз повторю — это не коробка, пишите свой код.

                  >> спорно github.com/yiisoft/yii2/blob/master/framework/db/BaseActiveRecord.php#L1198 и зачем делать линовку, для модели которая уже сохранена? так же уже должны быть проставлены ключи

                  откуда ключи будут проставлены, если вручную вы их не ставите. Link как раз их и ставит.
                  Проверьте. Link не делает сохранение несохраненной модели.

                  >> Без примера кода не поверю, что связь будет именно на ту модель которая мне нужна. Я верю что можно создать модель с аналогичным неймспейсом и в контейнере (точнее в classmap) указать, чтобы пользовалась она. Но нам надо модель переписать всю с нуля, т.к. расшириться мы от нее не сможем (неймспейс мы переопределили)

                  github.com/zelenin/yii2-semantic-ui#usage (ссылками не ставится к сожалению) снизу пример переопределения стандартных классов классами расширения, причем классы расширения наследуются от перекрываемых стандлартных

                  >> пока не заметил

                  вы предполагаете, я утверждаю)
                    –1
                    Link не делает сохранение несохраненной модели.

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

                    вы предполагаете, я утверждаю)

                    громко, очень громко
                      0
                      если вы не можете читать код, с пониманием, что оно делает, то просто дебажьте. xdebug
                        0
                        Ваши комментарии перерастают в хамство и попытку унизить меня и возвысить себя, вам сюда или сюда
                        и больше просьба не писать всякую чушь под данным хабом
                          0
                          вы отзеркалили мой комментарий (http://habrahabr.ru/post/254179/#comment_8348909) — недостойный прием для дискуссии.
                          По link заканчиваю дискуссию — не имеет смысла бросаться ссылками. Нужны фактические док-ва с моей или вашей стороны.
                            0
                            вы отзеркалили мой комментарий

                            подайте на меня в суд — за плагиат
                              0
                              вот вы как настроены, поскандалить — я все же думал будет дискуссия. Ок, подождем других комментаторов.
                                0
                                Я не веду дискуссий с неадекватными людьми, именно поэтому на yii форуме вы у меня в черном списке появились, практически сразу, как только зарегистрировались там. Здесь я попытался с вами дискутировать, но кроме как унижать, и восхвалять себя вы ничего не умеете. Все ваши доводы бездоказательны, ни одной ссылки я не увидел, доказывающей вашей правоты, а то что вы любите спорить и провоцировать людей знают все пользователи вышеупомянутого форума. Я открыт для адекватных дискуссий, а лазить по репозиторию и тыкать вас в ссылки мне не доставляет никакого удовольствия. Вы здесь уже натроллили столько вещей, которые я опровергнул, что дальнейшую дискуссию не хочется вести. Я думал на данном ресурсе вы ведете себя более адекватно, но в очередной раз убедился, как завышено ваше ЧСВ.
                                  0
                                  ну странно. Про себя я вообще не писал. А мои доводы вы только один опровергли и то, ссылкой на ссылку.
                      0
                      github.com/zelenin/yii2-semantic-ui#usage (ссылками не ставится к сожалению) снизу пример переопределения стандартных классов классами расширения, причем классы расширения наследуются от перекрываемых стандлартных

                      это вообще не имеет никакого отношения к связям моделей из разных модулей
                        0
                        github.com/zelenin/yii2-semantic-ui#usage

                        вы пробовали кстати данный метод переопределения через di? Засомневался, что он будет работать, Вы предлагаете:
                        Yii::$container->set(\yii\grid\GridView::className(), \Zelenin\yii\SemanticUI\widgets\GridView::className());
                        

                        т.е. переопределяете класс, но в самом классе вы ссылаетесь на него же (он же переопределен):
                        namespace Zelenin\yii\SemanticUI\widgets;
                        class GridView extends \yii\grid\GridView
                        


                        Autoload тут разве сработает как задумали Вы?
                          0
                          Это мое расширение — конечно я все пробовал.
                            0
                            только что проверил, добавил секцию UPD в хаб
                              0
                              я кстати не совсем понял, что вы имели в виду связь между моделями. Подумал, что вы наследование имеете в виду.
                              Но смысла это не меняет. Через контейнер рулим всеми зависимостями. При необходимости пишем интерфейсы
                    +3
                    Бесполезная статья (начиная от названия — ожидал увидеть список планируемых нововведений с их кратким обзором ) и только запутает новичков, автор либо брезгует документацией и чтением исходников, или просто ленится разобраться, и додумывает свои объяснения непонятным ему моментам. Я не хочу задеть или обидеть автора, но тем не менее.

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

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

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

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

                      Пример находится в хабе — «домашка».
                      0
                      Столько людей считают basic/advanced шаблоны истиной в последней инстанции что уж лучше бы их вообще удалили, такое ощущение что люди даже не подозревают что это пример а не обязательные требования.

                        0
                        не спорю, это пример, я не утверждал нигде, что это ядро фреймворка, любой пример учит как использовать то или иное, я лишь высказал, что это не совсем корректно, с моей точки зрения — заметьте — я ее никому не навязываю
                            0
                            .
                            0
                            С момента прочтения заголовка был уверен — будет срач.
                              0
                              Валидаторы не создаются при инициализации модели, а непосредственно перед самой валидацией.
                                0
                                Вы правы, — валидаторы создаются при обращении, но так же обращение происходит при генерации сценариев и если вы не перекрывали этот метод, то будут они созданы при получении списка активных аттрибутов или списка безопасных аттрибутов (\yii\base\Model::safeAttributes()).
                                +1
                                Очень многое в статье, мягко говоря, не совсем верно, но кое-что полезное для себя вынес. Пишите ещё, только факты надо проверять, всё-таки, получше…
                                  0
                                  спасибо за ваш комментарий, статья и была написана ради критики, можно озвучить моменты, которые здесь описаны неверно?
                                    0
                                    В основном, их уже озвучили в комментариях.
                                  +1
                                  Возможно я не прав, но ряд тезисов:
                                  • Шаблон, от разработчиков должен скорее показывать как правильно делать, а не являться шаблоном для старта очередного приложения опытным разработчиком. У него в силу своих предпочтений и опыта будет свой шаблон значительно более сложный.
                                    Так что комментарии что в шаблоне ляпы, что он не истина в последней инстанции, скорее несостоятельны. Ведь этот шаблон поставят именно те кто будет проходить «The Definitive Guide to Yii 2.0». Значете как правильно — лучше пулл реквест, чем очередной комментарий.
                                  • Начиная с первых версий фреймворка пользователи постоянно и неумолимо говорят о проблеммах организации модульной структуры в YII, все это выражалось и просьбами своего URL менеджера и какого-нибудь инсталлятора для модуля. На что часто получали ответ что YII не CMS… Хотя «переход в мир composer», тоько усугубит положение. Но и положительные сдвиги тоже есть (отдельное спасибо за BootstrapInterface).
                                    Множество расширений оформлены ввиде модулей и необходимые изменения в них зачастую выливаются в такие инструкции, а необходимость связей между модулями возникает постоянно и порождает ТВОРЧЕСТВО.
                                    Я думаю что ответ на вопрос связи между компонентами разных модулей должен быть дан именно разработчиками фреймворка и быть более менее однозначным. Возможно нужна статья, возможно это стоит добавить в шаблон. Если он ответит на такие вопросы это будет очень замечательно:
                                    1. Берем любой модуль из composer и хотим назначить ему права из своего модуля rbac
                                    2. Использование модели user из внешнего модуля по всему своему проекту, к примеру для формирования ссылки на профиль автора и т.д.

                                  А вообще автор молодец. Он поднял нужные вопросы и я надеюсь мы вместе сделаем фреймворк лучше.
                                    0
                                    шаблон является примером ОРГАНИЗАЦИИ кода внутри приложения.

                                    Какие вы видите проблемы модульной организации?

                                    Связь между компонентами работает через di.
                                      0
                                      связь моделей не будет работать через di, через контейнер работают только объекты создающиеся через Yii::createObject(), а то что создается через new ArModel надо перекрывать через classMap, что не позволит унаследоваться от одноименного класса, как это делало поведение в di контейнере, что опять же повторюсь, является больше странным поведением, чем фишкой.
                                        0
                                        habrahabr.ru/post/254179/#comment_8348781
                                        имею в виду контейнер
                                          0
                                          Какая связь модулей может быть через контейнер? Конкретно тупиковая ситуация — связь моделей, а они создаются не через контейнер.
                                            0
                                            давайте продолжим более конструктивно. Конкретный пример — я вам конкретное решение.
                                              0
                                              читайте выше

                                              >Конкретно тупиковая ситуация — связь моделей
                                                0
                                                связь моделей — это абстрактно. Конкретно: у меня есть то-то, хочу то-то.
                                                  –1
                                                  конкретно надо читать хаб, чтобы не задавать глупых вопросов
                                                    0
                                                    Вот это я понимаю дискуссия. Располагает к развитию.
                                                      0
                                                      Вам уже некуда развиваться, вы «гуру», но все же процитирую строки из хаба, раз вам лень прокручивать страницу вверх, там все было изложено:

                                                      Рассмотрим пример: подключив 2 модуля User и BankAccount, мы должны связать между собой модели User и UserAccount.
                                                        0
                                                        Держитесь в рамках уважительной дискуссии.

                                                        На этот кейс вам уже написали решение. В UPD вы написали несколько дней назад, что проверите его. Не получилось?
                                                          0
                                                          извините, но ваши слова:

                                                          Конкретный пример — я вам конкретное решение.


                                                          отказываетесь от них? я вам 10 раз уже повторил конкретный пример, который написан в хабе.

                                                          и объяснил, что с моделями не получилось в этом комментарии habrahabr.ru/post/254179/#comment_8360471

                                                          Вы или уже троллите или просто пытаетесь спровоцировать меня на какие то грубости, увидев выше, что сообщество плюсует вас и минусует меня по аналогичным провокациям.
                                                            0
                                                            вы в комменте по ссылке указали как с этим работать. Делаете расширяемый экстеншн — создавайте объекты через Yii::createObject(). тогда они будут доступны через контейнер DI. Я днем искал, но не смог найти пару расширений, которые широко используют Yii::createObject(). Остальные юзают свои костыли типа класс-менеджеров или класс-мапов.
                                                            Вы хотите встроенного решения — оно есть. Хотите еще одно?
                                                              0
                                                              ну точно тролль, покажите обещанный код

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

                                                              p.s. по этой же причине нельзя создавать модели через контейнер
                                                                0
                                                                поуважительнее, повторяю.
                                                                конкретнее, повторяю.
                                                                Конкретный код покажите, в котором вы видите проблему. Я не понимаю, что вы имете в виду под «модели невозможно конфигурировать по ряду причин, одной из них является создание модели, как связанной по ключу.».
                                                                  0
                                                                  Еще раз повторю — перечитайте хаб, там все есть и даже есть пример из симфони, как это реализовано там.
                                                                  Есть такая поговорка — «замахнулся — бей» у вас пока только пустые слова.
                                                                  Напишите, как связать модели из разных модулей, не надо придумывать расширения, которые якобы создают модели через di контейнер — это не возможно на коробочном ActiveRelationTrait
                                                                    0
                                                                    UPD код не вставился, сейчас ссылками накидаю
                                                                      0
                                                                      имеем две модели из двух расширений:
                                                                      pastebin.com/5A5AsMRn
                                                                      pastebin.com/cHHuLawE

                                                                      нам нужно связать две модели через relation. Создаем свою модель со связью, наследуемую от модели расширения:
                                                                      pastebin.com/CP5MWYEk

                                                                      Через di маппим модель расширения на нашу модель и через di же к ней обращаемся:
                                                                      pastebin.com/B3E4wWGH
                                                                        0
                                                                        1. про это и была речь в хабе

                                                                        Если вы решили «домашку», попробуйте решить ее снова, но не перекрывая обе модели из модулей.

                                                                        для 2 модели нужна обратная связь и 2 модель тоже надо расширять.

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

                                                                        2. не вижу смысла в
                                                                        public $className = 'UserModelCustom';


                                                                        3. ваш вариант подразумевает создание модели через контейнер в контроллере, ну или как минимум в статическом методе модели `MyModel::create()`

                                                                        4. Вернемся к нашим ActiveRecord и ActiveQuery, теперь помимо того, что ActiveQuery и так был завязан на класс модели, мы его завязываем уже на объект, т.е. чтобы использовать !ActiveQuery! нам нужно создать новый ActiveRecord — вы до сих пор не видите тут проблему? И еще учтите что di контейнер не создает объект при каждом обращении, а передает ранее созданный объект (сервис) по ссылке!
                                                                          0
                                                                          1. Модуль BankAccount не может быть самодостаточен, т.к. явно зависит от модели User.
                                                                          Если для второй модели нужна обратная связь, то добавьте. Я же скинул сниппеты.
                                                                          2. Этот атрибут для проверки и демонстрации маппинга моделей. Для функционала не нужен.
                                                                          3. Не понял. Какой контейнер в контроллере и зачем метод create?
                                                                          4. Согласен, минус — чтобы воспользоваться find() нам нужно создать объект. Можно из Yii::$container->getDefinitions() достать маппинг — там будет имя класса строкой. Но это уже не будет прозрачной работой.
                                                                          Тем не менее этим можно пользоваться.
                                                                          di создает объект каждый раз. там даже есть два разных типа: definition и singleton. А вот service locator возвращает всегда один и тот же объект.

                                                                          Проблему я понял, с вами частично согласен, но тем не менее из коробки это обходиться без написания своих костылей.
                                                                            0
                                                                            1. зависимость должна описываться интерфейсом (опять смотрим, как это реализовано в доктрине), пусть даже через контейнер, чтото похожее на это.
                                                                            2. привык верить $model->classname()
                                                                            3. в вашем варианте или в контроллере обращаться к контейнеру или же обращаться к модели через статику, в которой будет спрятана эта логика по созданию объекта из контейнера
                                                                            4. в контроллере появится запись вида
                                                                            Yii::$container->getDefinitions()[MyModel::classname()]['class']


                                                                            без написания своих костылей.

                                                                            в 4 пункте это и есть свой костыль из подручных средств, что не прозрачно и человеку поддерживаемому код можно заработать опухоль мозга
                                                                              0
                                                                              1. Ради бога. Неважно.
                                                                              2. Чтобы избежать ненужной неоднозначности.
                                                                              3. Это уже на откуп девелоперской реализации. Неважно.
                                                                              4. Ок, принято.
                                      0
                                      ну наконец-то отметились, я уж думал деньги получили и пропали :D

                                      А по существу, очень рад вашему комментарию и тому, что я не один думаю о проблемах, что кто то кроме меня видит эти проблемы. Мне так же хотелось услышать мнение разработчиков по этому всему, но они почему-то решили промолчать — обидно :(
                                      На следующей неделе, возможно чуть позже, планирую написать статью о «хороших практиках» программирования на данном фреймворке, т.к. к критике кода пока сообщество не готово, хотя именно критика двигатель к успешному коду. Так же в данной статье не была затронута проблема, которой уже около года и куча ишью по этому поводу — это хранение представлений в бд, казалось бы — делов то — но при подходе в разработке renderer и view не была заложена такая функциональность и теперь надо ломать обратную совместимость, хочется верить, что скоро все таки разработчики дадут нам эту «плюшку»
                                        0
                                        не знаю чего вы ждете. Вы уже получили хороший фидбэк от мэнтейнера проекта и практикующих разработчиков на yii2 с разработками в паблике.
                                          0
                                          хранение представлений в бд

                                          Странная хотелка.
                                          Представление тесно связано с данными передаваемыми из контроллера. Вьювы в БД и контроллеры c остальным кодом под контролем версий могут превратиться в постоянный источник багов за счет несогласованности одного с другим.
                                            0
                                            Есть такое понятие — миграции, да и по вашей логике rbac должен быть только в PhpManager.
                                              0
                                              Каким вы видите способ удобного обновления кода вьювов через миграцию?

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

                                              Полная замена строки со старым кодом на новый? Тогда в чем смысл того что он лежал в базе и был доступен на редактирование?

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

                                              RBAC неудачный пример. DbManager не хранит код в БД, он хранит связи.
                                                0
                                                Во первых это дело каждого, что и как обновлять, можно при выходе релиза все изменения опять перепаковывать в 1 миграцию, а можно просто не обновлять, если изменения коснулись стилей или разметки. Во вторых для вью можно сделать отдельную бд с внешними подключениями. В третьих я имел ввиду конечно же не «php шаблонизатор», а «смарти» или «твиг». В 4 никто не мешает вам сделать импортер из .twig.php файлов в бд (вы же надеюсь хранение ролей именно так организовываете, при использовании yii\rbac\DbManager? — правите rbac/init команду, а уже она делает логику импорта, будь-то через truncate (если нет fk) или через 'update|replace'.
                                                  0
                                                  Не убедительно. Выглядит как усложнение ради усложнения.
                                                  Твиг и смарти — такой же частный случай шаблонизаторов как и нативный php.
                                                  Такие вещи, если в них действительно есть объективная необходимость, решаются на уровне проекта а не фреймворка.
                                                    0
                                                    посмотрите метод render, шаблон и файл это разные вещи, называть нужно вещи своими именами, к примеру — renderFile(). Почему вы считаете логичным, что шаблоны обязаны храниться в файлах это лично ваше дело, но я больше солидарен в этом вопросе с популярными «шаблонизаторами»:

                                                    Smarty Resources
                                                    Twig Loaders

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

                                                      Не «файлы vs база», а «код vs контент». Развернуть тезис?

                                                      Далее… Капитан-очевидность утверждает, что:

                                                      • Код под контролем версий, контент — нет.
                                                      • Вьюв — неотъемлемая часть кода.
                                                      • Сознательный вынос вьюва из под контроля версий без объективных причин — выглядит странно, и обещает проблемы.
                                                      • Костыли, которыми это все потом будет синхронизироваться — необоснованное усложнение системы.


                                                      Если же все-таки вы не строите проект «Абстрактный конь в вакууме» объективные причины имеются, то может и вопрос решать стоит на уровне проекта и его технических условий? Вы же сами написали:

                                                      это дело каждого, что и как обновлять

                                                      Значит уровень проекта. И при этом ожидаете универсальное решение. Упорно долбите в вопрос «Как?» прежде чем ответить «Зачем?». Отсюда и большая часть вашей критики похожа на поверхностное «бла-бла-бла».

                                                      Сделайте полезное: сформулируйте свой вопрос, обоснуйте, отпишите в баг-трекер. Комьюнити хорошо реагирует на адекватные идеи.

                                                      Оффтоп
                                                      Да, и не нужно приписывать мне то, чего нет.

                                                      шаблон и файл это разные вещи, называть нужно вещи своими именами

                                                      Я не утверждал обратного ни по поводу вещей ни по поводу имен.

                                                      Почему вы считаете логичным, что шаблоны обязаны храниться в файлах это лично ваше дело

                                                      Не в файлах, а в коде под контролем версий (см. выше).

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

                                                      Не может. Для меня норма — здравый смысл. А он зависит от ситуации.
                                                        0
                                                        Код под контролем версий, контент — нет.

                                                        цитату покажите, где я УТВЕРЖДАЛ, а не как из один возможных вариантов решения предложил

                                                        Вьюв — неотъемлемая часть кода.
                                                        и
                                                        «код vs контент».

                                                        разжуйте свой тезис, а то я уже стал сомневаться, что вы имели ввиду вначале, а позже сами контент называете кодом + я это не утверждал

                                                        Сознательный вынос вьюва из под контроля версий без объективных причин — выглядит странно, и обещает проблемы.

                                                        так же не утверждал

                                                        Костыли, которыми это все потом будет синхронизироваться — необоснованное усложнение системы.

                                                        и это не утверждал — вы похоже свои мысли выдаете за мои утверждения

                                                        Если же все-таки вы не строите проект «Абстрактный конь в вакууме» объективные причины имеются, то может и вопрос решать стоит на уровне проекта и его технических условий? Вы же сами написали:

                                                        Давайте в sfiwt mailer уберем возможность конфигурировать транспорты — пусть решают на уровне проекта! Урежем весь функционал, чего уж мелочиться на шаблонизаторах. Почему нельзя сделать возможным конфигурировать loader — они все под интерфейсом -я лично не вижу проблемы в этом, а вижу хардкор, с которым вы соглашаетесь!

                                                        Значит уровень проекта. И при этом ожидаете универсальное решение. Упорно долбите в вопрос «Как?» прежде чем ответить «Зачем?». Отсюда и большая часть вашей критики похожа на поверхностное «бла-бла-бла».

                                                        Зачем вы читаете мое «бла-бла-бла» вместо полезной литературы по ООП?

                                                        Сделайте полезное: сформулируйте свой вопрос, обоснуйте, отпишите в баг-трекер. Комьюнити хорошо реагирует на адекватные идеи.

                                                        опаньки «нежданчик» — смотрим так же на число

                                                        — не увидел у вас не одного обоснования почему это должно быть на уровне проекта, вы лишь пытаетесь навязать мне проблемы, которые вы не смогли бы решить в системе контроля версий.
                                                          0
                                                          Вы меня не услышали, и опять все поняли по-своему.
                                                          Дальнейшую дискуссию считаю бессмысленной.
                                                          0
                                                          в rbac вам так же лучше не вникать, ну по крайней мере yii\rbac\DbManager, там тоже у вас с системами контроля версий будут проблемы

                                        Only users with full accounts can post comments. Log in, please.