Комментарии 83
Не использовал на полную yii, но пишу на похожем
Не люблю такое, лучше уж отдельный метод сделать и его использовать, а то будет обязательное такое место, где не надо ['status' => 'active'] и тогда полная путаница начнется. Не говоря уже о том, что привыкаешь к тому что такие методы как find работают прозрачно и надо самому правильно составить запрос, без всяких значений по-умолчанию
Чтобы наложить условие по умолчанию на ActiveQuery, нам нужно расширить ActiveRecord.
public static function find()
{
return parent::find()->andWhere(['status' => 'active']);
}
Не люблю такое, лучше уж отдельный метод сделать и его использовать, а то будет обязательное такое место, где не надо ['status' => 'active'] и тогда полная путаница начнется. Не говоря уже о том, что привыкаешь к тому что такие методы как find работают прозрачно и надо самому правильно составить запрос, без всяких значений по-умолчанию
User::findByUsername('ok')Не знаю как yii, у меня примерно так:
User::findByUsername('ok', ['status' => 'active'])вторым аргументом можно уточнить условие выборки
но имхо лучше не делать так, как в advanced template, а вынести это в виду скоупов. Если уж finder у нас в модели в виде объекта ActiveQuery, то и различные алиасы типа findByUsername надо вынести в него — этому не место в модели.
согласен, в своих проектах делаю скоуп byUsername, а точнее byLogin, т.к. в качестве логина может выступать не только username, но и email
Простите, немного запутался. А для чего другим моделям нужен будет явный метод findByUsername, конечно при условии что все модели наследуют новый класс ActiveQuery? Подобные методы обычно создаются через магические методы __call и __callStatic, поэтому я думал что лучше просто переопределить, в данном случаи __callStatic, и научить его использовать второй аргумент как уточняющий условие выборки. Реальных методов вроде User::findByUsername не будет у моделей.
В целом я исхожу от общей практики yii к статическим помощникам, поэтому такие вещи и оказываются в модели. Извиняюсь, если неправильно понял, я лишь свое мнение написал про пост, yii не так хорошо знаю
В целом я исхожу от общей практики yii к статическим помощникам, поэтому такие вещи и оказываются в модели. Извиняюсь, если неправильно понял, я лишь свое мнение написал про пост, yii не так хорошо знаю
Много способов реализации, я хотел подчеркнуть то, что ради добавления условия выборки мы расширям модель, а именно эту ненужную связь — это 2 разные сущности, но при расширении query надо перекрывать обе
вы почему-то считаете, что вам надо перекрывать метод из adavnced template. Это не то, что вы называете «коробкой». Это кем-то написанный код для примера, который, уверен, при создании issue с объяснением, будет вынесен в UserQuery.
Не надо тащить к себе в проект код из примера — делайте свой.
Вообще часто пишут «в yii2», имея в виду templates. Но это всего лишь примеры организации кода.
Не надо тащить к себе в проект код из примера — делайте свой.
Вообще часто пишут «в yii2», имея в виду templates. Но это всего лишь примеры организации кода.
код написан не кем то, а разработчиками, и большинство программистов берут за основу практики из него
ради бога) но в документации написано, что класс user должен реализовывать IdentityInterface, а не браться из template. А вы конечно можете брать, что угодно, но как минимум это к фреймворку не относится.
Если бы «разработчик фреймворка» означало разработчика безгрешного и пишущего правильно, то у нас был бы один хороший фреймворк, а не несколько.
Вы сами согласились, что хелпер в модели надо заменить на скоуп, но считаете, что темплейт надо взять как непреложный базис для вашего приложения.
Посмотри пример и сделай правильно. Фреймворк ты не можешь исправить (можешь конечно), а сделать правильно приложение — да, не исправляя чужие ошибки или несуразности, а не внося их в проект.
Если бы «разработчик фреймворка» означало разработчика безгрешного и пишущего правильно, то у нас был бы один хороший фреймворк, а не несколько.
Вы сами согласились, что хелпер в модели надо заменить на скоуп, но считаете, что темплейт надо взять как непреложный базис для вашего приложения.
Посмотри пример и сделай правильно. Фреймворк ты не можешь исправить (можешь конечно), а сделать правильно приложение — да, не исправляя чужие ошибки или несуразности, а не внося их в проект.
ради бога) но в документации написано, что класс user должен реализовывать IdentityInterface
На сколько мне известно, отвязку от интерфейса убрали в фреймворке давно, сейчас имплементация данного интерфеса лишь условность.
Странность в этом интерфейсе все равно — остается — он только для рест приложений? или это нормально кидать исключения при реализации методов интерфейса? может этому место в rest/models, а не в common/models?
Эта статья была создана не с целью «обгадить фреймворк», не надо во мне видеть врага
или это нормально кидать исключения при реализации методов интерфейса?
Вставлю свои пять копеек.
Вы даёте ссылку на демо-шаблон приложения, в котором не реализован некий метод интерфейса IdentityInterface.
Каковы в данном случае претензии к фреймворку?
Да и к демо-шаблону нет претензий в данном случае. Ну не реализован там этот метод, да. Что (и главное ЗАЧЕМ) вы предлагаете там вставить? die('error'); что ли? или return null;? Какое-то копание в ненужных деталях получается.
Статью, кстати, плюсанул. Люблю такие темы. Обычно много нового узнаёшь по ходу чтения комментариев.
вы — автор статьи — сильно плаваете в теме, делая необоснованные предположения.
Я не вижу в вас врага и прекрасно понимаю, что yii2 — не самое лучшее творение человека, но практически все ваши утверждения необоснованы.
Я не вижу в вас врага и прекрасно понимаю, что yii2 — не самое лучшее творение человека, но практически все ваши утверждения необоснованы.
Я опровергнул множество ваших коментариев, а это говорит о том, что судить о том как я плаваю — явно не вам — вы тогда тонете
например? Что вы опровергли? Я вам пишу факты, вы отвечаете: не уверен, не думаю, что это будет работать итд.
Все, что я пишу из фактического — проверено.
Все, что я пишу из фактического — проверено.
это уже явно направленное против меня замечание, т.к. касается оно опечатки в ТЕКСТЕ из примера использования виджета — это не код, а текст в демо.
Обсуждайте свою статью — не надо искать косяков в других местах, не надо доказывать, что вы лучше меня знаете yii. Я вам предлагаю факты — вы можете их опровергнуть другими фактами. То, что делаете вы, как минимум некрасиво.
Обсуждайте свою статью — не надо искать косяков в других местах, не надо доказывать, что вы лучше меня знаете yii. Я вам предлагаю факты — вы можете их опровергнуть другими фактами. То, что делаете вы, как минимум некрасиво.
начнем с того, что 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 посещают данный ресурс, хотелось бы извиниться перед ними. Возможно, я где то наврал — буду рад любым комментариям ниже.
я опроверг все ваши основные тезисы. Собственно чего-то действительно правдивого я тут и не заметил.
Рад буду дискуссии.
>> На первый взгляд все логично, не считая того факта, что в коробке в 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 посещают данный ресурс, хотелось бы извиниться перед ними. Возможно, я где то наврал — буду рад любым комментариям ниже.
я опроверг все ваши основные тезисы. Собственно чего-то действительно правдивого я тут и не заметил.
Рад буду дискуссии.
ничего не нужно перекрывать. Можно использовать любые варианты.
Начну с того, что в 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) указать, чтобы пользовалась она. Но нам надо модель переписать всю с нуля, т.к. расшириться мы от нее не сможем (неймспейс мы переопределили)
я опроверг все ваши основные тезисы. Собственно чего-то действительно правдивого я тут и не заметил.
пока не заметил
>>Начну с того, что в 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 (ссылками не ставится к сожалению) снизу пример переопределения стандартных классов классами расширения, причем классы расширения наследуются от перекрываемых стандлартных
>> пока не заметил
вы предполагаете, я утверждаю)
я про скоуп и 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 (ссылками не ставится к сожалению) снизу пример переопределения стандартных классов классами расширения, причем классы расширения наследуются от перекрываемых стандлартных
>> пока не заметил
вы предполагаете, я утверждаю)
Link не делает сохранение несохраненной модели.
трудно с вами спорить, вы уже в какой раз приводите бездоказательные доводы, которые я могу опровергнуть одной ссылкой на гитхаб.
я лично не вижу проверки перед сохранением
вы предполагаете, я утверждаю)
громко, очень громко
если вы не можете читать код, с пониманием, что оно делает, то просто дебажьте. xdebug
вы отзеркалили мой комментарий (http://habrahabr.ru/post/254179/#comment_8348909) — недостойный прием для дискуссии.
По link заканчиваю дискуссию — не имеет смысла бросаться ссылками. Нужны фактические док-ва с моей или вашей стороны.
По link заканчиваю дискуссию — не имеет смысла бросаться ссылками. Нужны фактические док-ва с моей или вашей стороны.
вы отзеркалили мой комментарий
подайте на меня в суд — за плагиат
вот вы как настроены, поскандалить — я все же думал будет дискуссия. Ок, подождем других комментаторов.
Я не веду дискуссий с неадекватными людьми, именно поэтому на yii форуме вы у меня в черном списке появились, практически сразу, как только зарегистрировались там. Здесь я попытался с вами дискутировать, но кроме как унижать, и восхвалять себя вы ничего не умеете. Все ваши доводы бездоказательны, ни одной ссылки я не увидел, доказывающей вашей правоты, а то что вы любите спорить и провоцировать людей знают все пользователи вышеупомянутого форума. Я открыт для адекватных дискуссий, а лазить по репозиторию и тыкать вас в ссылки мне не доставляет никакого удовольствия. Вы здесь уже натроллили столько вещей, которые я опровергнул, что дальнейшую дискуссию не хочется вести. Я думал на данном ресурсе вы ведете себя более адекватно, но в очередной раз убедился, как завышено ваше ЧСВ.
github.com/zelenin/yii2-semantic-ui#usage (ссылками не ставится к сожалению) снизу пример переопределения стандартных классов классами расширения, причем классы расширения наследуются от перекрываемых стандлартных
это вообще не имеет никакого отношения к связям моделей из разных модулей
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 тут разве сработает как задумали Вы?
Бесполезная статья (начиная от названия — ожидал увидеть список планируемых нововведений с их кратким обзором ) и только запутает новичков, автор либо брезгует документацией и чтением исходников, или просто ленится разобраться, и додумывает свои объяснения непонятным ему моментам. Я не хочу задеть или обидеть автора, но тем не менее.
Приведите, пожалуйста, пример проблем при конфигурировании модулей, хочется разобраться с этим вопросом.
Приведите, пожалуйста, пример проблем при конфигурировании модулей, хочется разобраться с этим вопросом.
и только запутает новичков
мне кажется наоборот, новички сразу будут знать о подводных камнях, а благодаря комментариям еще и возможные способы решения одной и той же задачи, что позволит выбрать оптимальный вариант для «себя».
автор либо брезгует документацией и чтением исходников, или просто ленится разобраться
Позвольте спросить, с чего такие выводы? Документацию действительно я не читаю, читаю только код, и слежу за всеми ишью на гитхабе, которые тоже задевают и документацию в том числе.
Приведите, пожалуйста, пример проблем при конфигурировании модулей, хочется разобраться с этим вопросом.
Пример находится в хабе — «домашка».
извините ошибся веткой — к этому
Столько людей считают basic/advanced шаблоны истиной в последней инстанции что уж лучше бы их вообще удалили, такое ощущение что люди даже не подозревают что это пример а не обязательные требования.
С момента прочтения заголовка был уверен — будет срач.
Валидаторы не создаются при инициализации модели, а непосредственно перед самой валидацией.
Вы правы, — валидаторы создаются при обращении, но так же обращение происходит при генерации сценариев и если вы не перекрывали этот метод, то будут они созданы при получении списка активных аттрибутов или списка безопасных аттрибутов (\yii\base\Model::safeAttributes()).
Очень многое в статье, мягко говоря, не совсем верно, но кое-что полезное для себя вынес. Пишите ещё, только факты надо проверять, всё-таки, получше…
Возможно я не прав, но ряд тезисов:
А вообще автор молодец. Он поднял нужные вопросы и я надеюсь мы вместе сделаем фреймворк лучше.
- Шаблон, от разработчиков должен скорее показывать как правильно делать, а не являться шаблоном для старта очередного приложения опытным разработчиком. У него в силу своих предпочтений и опыта будет свой шаблон значительно более сложный.
Так что комментарии что в шаблоне ляпы, что он не истина в последней инстанции, скорее несостоятельны. Ведь этот шаблон поставят именно те кто будет проходить «The Definitive Guide to Yii 2.0». Значете как правильно — лучше пулл реквест, чем очередной комментарий. - Начиная с первых версий фреймворка пользователи постоянно и неумолимо говорят о проблеммах организации модульной структуры в YII, все это выражалось и просьбами своего URL менеджера и какого-нибудь инсталлятора для модуля. На что часто получали ответ что YII не CMS… Хотя «переход в мир composer», тоько усугубит положение. Но и положительные сдвиги тоже есть (отдельное спасибо за BootstrapInterface).
Множество расширений оформлены ввиде модулей и необходимые изменения в них зачастую выливаются в такие инструкции, а необходимость связей между модулями возникает постоянно и порождает ТВОРЧЕСТВО.
Я думаю что ответ на вопрос связи между компонентами разных модулей должен быть дан именно разработчиками фреймворка и быть более менее однозначным. Возможно нужна статья, возможно это стоит добавить в шаблон. Если он ответит на такие вопросы это будет очень замечательно:
- Берем любой модуль из composer и хотим назначить ему права из своего модуля rbac
- Использование модели user из внешнего модуля по всему своему проекту, к примеру для формирования ссылки на профиль автора и т.д.
А вообще автор молодец. Он поднял нужные вопросы и я надеюсь мы вместе сделаем фреймворк лучше.
шаблон является примером ОРГАНИЗАЦИИ кода внутри приложения.
Какие вы видите проблемы модульной организации?
Связь между компонентами работает через di.
Какие вы видите проблемы модульной организации?
Связь между компонентами работает через di.
связь моделей не будет работать через di, через контейнер работают только объекты создающиеся через Yii::createObject(), а то что создается через new ArModel надо перекрывать через classMap, что не позволит унаследоваться от одноименного класса, как это делало поведение в di контейнере, что опять же повторюсь, является больше странным поведением, чем фишкой.
habrahabr.ru/post/254179/#comment_8348781
имею в виду контейнер
имею в виду контейнер
Какая связь модулей может быть через контейнер? Конкретно тупиковая ситуация — связь моделей, а они создаются не через контейнер.
давайте продолжим более конструктивно. Конкретный пример — я вам конкретное решение.
читайте выше
>Конкретно тупиковая ситуация — связь моделей
>Конкретно тупиковая ситуация — связь моделей
связь моделей — это абстрактно. Конкретно: у меня есть то-то, хочу то-то.
конкретно надо читать хаб, чтобы не задавать глупых вопросов
Вот это я понимаю дискуссия. Располагает к развитию.
Вам уже некуда развиваться, вы «гуру», но все же процитирую строки из хаба, раз вам лень прокручивать страницу вверх, там все было изложено:
Рассмотрим пример: подключив 2 модуля User и BankAccount, мы должны связать между собой модели User и UserAccount.
Держитесь в рамках уважительной дискуссии.
На этот кейс вам уже написали решение. В UPD вы написали несколько дней назад, что проверите его. Не получилось?
На этот кейс вам уже написали решение. В UPD вы написали несколько дней назад, что проверите его. Не получилось?
извините, но ваши слова:
отказываетесь от них? я вам 10 раз уже повторил конкретный пример, который написан в хабе.
и объяснил, что с моделями не получилось в этом комментарии habrahabr.ru/post/254179/#comment_8360471
Вы или уже троллите или просто пытаетесь спровоцировать меня на какие то грубости, увидев выше, что сообщество плюсует вас и минусует меня по аналогичным провокациям.
Конкретный пример — я вам конкретное решение.
отказываетесь от них? я вам 10 раз уже повторил конкретный пример, который написан в хабе.
и объяснил, что с моделями не получилось в этом комментарии habrahabr.ru/post/254179/#comment_8360471
Вы или уже троллите или просто пытаетесь спровоцировать меня на какие то грубости, увидев выше, что сообщество плюсует вас и минусует меня по аналогичным провокациям.
вы в комменте по ссылке указали как с этим работать. Делаете расширяемый экстеншн — создавайте объекты через Yii::createObject(). тогда они будут доступны через контейнер DI. Я днем искал, но не смог найти пару расширений, которые широко используют Yii::createObject(). Остальные юзают свои костыли типа класс-менеджеров или класс-мапов.
Вы хотите встроенного решения — оно есть. Хотите еще одно?
Вы хотите встроенного решения — оно есть. Хотите еще одно?
ну точно тролль, покажите обещанный код
—
p.s. по этой же причине нельзя создавать модели через контейнер
—
модели невозможно конфигурировать по ряду причин, одной из них является создание модели, как связанной по ключу.
p.s. по этой же причине нельзя создавать модели через контейнер
поуважительнее, повторяю.
конкретнее, повторяю.
Конкретный код покажите, в котором вы видите проблему. Я не понимаю, что вы имете в виду под «модели невозможно конфигурировать по ряду причин, одной из них является создание модели, как связанной по ключу.».
конкретнее, повторяю.
Конкретный код покажите, в котором вы видите проблему. Я не понимаю, что вы имете в виду под «модели невозможно конфигурировать по ряду причин, одной из них является создание модели, как связанной по ключу.».
Еще раз повторю — перечитайте хаб, там все есть и даже есть пример из симфони, как это реализовано там.
Есть такая поговорка — «замахнулся — бей» у вас пока только пустые слова.
Напишите, как связать модели из разных модулей, не надо придумывать расширения, которые якобы создают модели через di контейнер — это не возможно на коробочном ActiveRelationTrait
Есть такая поговорка — «замахнулся — бей» у вас пока только пустые слова.
Напишите, как связать модели из разных модулей, не надо придумывать расширения, которые якобы создают модели через di контейнер — это не возможно на коробочном ActiveRelationTrait
UPD код не вставился, сейчас ссылками накидаю
имеем две модели из двух расширений:
pastebin.com/5A5AsMRn
pastebin.com/cHHuLawE
нам нужно связать две модели через relation. Создаем свою модель со связью, наследуемую от модели расширения:
pastebin.com/CP5MWYEk
Через di маппим модель расширения на нашу модель и через di же к ней обращаемся:
pastebin.com/B3E4wWGH
pastebin.com/5A5AsMRn
pastebin.com/cHHuLawE
нам нужно связать две модели через relation. Создаем свою модель со связью, наследуемую от модели расширения:
pastebin.com/CP5MWYEk
Через di маппим модель расширения на нашу модель и через di же к ней обращаемся:
pastebin.com/B3E4wWGH
1. про это и была речь в хабе
для 2 модели нужна обратная связь и 2 модель тоже надо расширять.
значит модуль не самодостаточен? надо регистрировать модель в контейнере прежде чем использовать модуль? в чем преимущество такого модуля для обычного пользователя (не программиста)?
2. не вижу смысла в
3. ваш вариант подразумевает создание модели через контейнер в контроллере, ну или как минимум в статическом методе модели `MyModel::create()`
4. Вернемся к нашим ActiveRecord и ActiveQuery, теперь помимо того, что ActiveQuery и так был завязан на класс модели, мы его завязываем уже на объект, т.е. чтобы использовать !ActiveQuery! нам нужно создать новый ActiveRecord — вы до сих пор не видите тут проблему? И еще учтите что di контейнер не создает объект при каждом обращении, а передает ранее созданный объект (сервис) по ссылке!
Если вы решили «домашку», попробуйте решить ее снова, но не перекрывая обе модели из модулей.
для 2 модели нужна обратная связь и 2 модель тоже надо расширять.
значит модуль не самодостаточен? надо регистрировать модель в контейнере прежде чем использовать модуль? в чем преимущество такого модуля для обычного пользователя (не программиста)?
2. не вижу смысла в
public $className = 'UserModelCustom';
3. ваш вариант подразумевает создание модели через контейнер в контроллере, ну или как минимум в статическом методе модели `MyModel::create()`
4. Вернемся к нашим ActiveRecord и ActiveQuery, теперь помимо того, что ActiveQuery и так был завязан на класс модели, мы его завязываем уже на объект, т.е. чтобы использовать !ActiveQuery! нам нужно создать новый ActiveRecord — вы до сих пор не видите тут проблему? И еще учтите что di контейнер не создает объект при каждом обращении, а передает ранее созданный объект (сервис) по ссылке!
1. Модуль BankAccount не может быть самодостаточен, т.к. явно зависит от модели User.
Если для второй модели нужна обратная связь, то добавьте. Я же скинул сниппеты.
2. Этот атрибут для проверки и демонстрации маппинга моделей. Для функционала не нужен.
3. Не понял. Какой контейнер в контроллере и зачем метод create?
4. Согласен, минус — чтобы воспользоваться find() нам нужно создать объект. Можно из Yii::$container->getDefinitions() достать маппинг — там будет имя класса строкой. Но это уже не будет прозрачной работой.
Тем не менее этим можно пользоваться.
di создает объект каждый раз. там даже есть два разных типа: definition и singleton. А вот service locator возвращает всегда один и тот же объект.
Проблему я понял, с вами частично согласен, но тем не менее из коробки это обходиться без написания своих костылей.
Если для второй модели нужна обратная связь, то добавьте. Я же скинул сниппеты.
2. Этот атрибут для проверки и демонстрации маппинга моделей. Для функционала не нужен.
3. Не понял. Какой контейнер в контроллере и зачем метод create?
4. Согласен, минус — чтобы воспользоваться find() нам нужно создать объект. Можно из Yii::$container->getDefinitions() достать маппинг — там будет имя класса строкой. Но это уже не будет прозрачной работой.
Тем не менее этим можно пользоваться.
di создает объект каждый раз. там даже есть два разных типа: definition и singleton. А вот service locator возвращает всегда один и тот же объект.
Проблему я понял, с вами частично согласен, но тем не менее из коробки это обходиться без написания своих костылей.
1. зависимость должна описываться интерфейсом (опять смотрим, как это реализовано в доктрине), пусть даже через контейнер, чтото похожее на это.
2. привык верить $model->classname()
3. в вашем варианте или в контроллере обращаться к контейнеру или же обращаться к модели через статику, в которой будет спрятана эта логика по созданию объекта из контейнера
4. в контроллере появится запись вида
в 4 пункте это и есть свой костыль из подручных средств, что не прозрачно и человеку поддерживаемому код можно заработать опухоль мозга
2. привык верить $model->classname()
3. в вашем варианте или в контроллере обращаться к контейнеру или же обращаться к модели через статику, в которой будет спрятана эта логика по созданию объекта из контейнера
4. в контроллере появится запись вида
Yii::$container->getDefinitions()[MyModel::classname()]['class']
без написания своих костылей.
в 4 пункте это и есть свой костыль из подручных средств, что не прозрачно и человеку поддерживаемому код можно заработать опухоль мозга
ну наконец-то отметились, я уж думал деньги получили и пропали :D
А по существу, очень рад вашему комментарию и тому, что я не один думаю о проблемах, что кто то кроме меня видит эти проблемы. Мне так же хотелось услышать мнение разработчиков по этому всему, но они почему-то решили промолчать — обидно :(
На следующей неделе, возможно чуть позже, планирую написать статью о «хороших практиках» программирования на данном фреймворке, т.к. к критике кода пока сообщество не готово, хотя именно критика двигатель к успешному коду. Так же в данной статье не была затронута проблема, которой уже около года и куча ишью по этому поводу — это хранение представлений в бд, казалось бы — делов то — но при подходе в разработке renderer и view не была заложена такая функциональность и теперь надо ломать обратную совместимость, хочется верить, что скоро все таки разработчики дадут нам эту «плюшку»
А по существу, очень рад вашему комментарию и тому, что я не один думаю о проблемах, что кто то кроме меня видит эти проблемы. Мне так же хотелось услышать мнение разработчиков по этому всему, но они почему-то решили промолчать — обидно :(
На следующей неделе, возможно чуть позже, планирую написать статью о «хороших практиках» программирования на данном фреймворке, т.к. к критике кода пока сообщество не готово, хотя именно критика двигатель к успешному коду. Так же в данной статье не была затронута проблема, которой уже около года и куча ишью по этому поводу — это хранение представлений в бд, казалось бы — делов то — но при подходе в разработке renderer и view не была заложена такая функциональность и теперь надо ломать обратную совместимость, хочется верить, что скоро все таки разработчики дадут нам эту «плюшку»
не знаю чего вы ждете. Вы уже получили хороший фидбэк от мэнтейнера проекта и практикующих разработчиков на yii2 с разработками в паблике.
хранение представлений в бд
Странная хотелка.
Представление тесно связано с данными передаваемыми из контроллера. Вьювы в БД и контроллеры c остальным кодом под контролем версий могут превратиться в постоянный источник багов за счет несогласованности одного с другим.
Есть такое понятие — миграции, да и по вашей логике rbac должен быть только в PhpManager.
Каким вы видите способ удобного обновления кода вьювов через миграцию?
Патчить регулярками? Не удобно, не наглядно, не гарантирует результат. Попробуйте взять этот вьюв, и пропатчить его чем-то более сложным чем просто переименовать переменную. Также, не забудьте о том, что код уже отредактировали пользователи, и он выглядит иначе.
Полная замена строки со старым кодом на новый? Тогда в чем смысл того что он лежал в базе и был доступен на редактирование?
И это при том что вы трижды выстрелили себе в ногу отказавшись от коробочных диффов доступных под контролем версий.
RBAC неудачный пример. DbManager не хранит код в БД, он хранит связи.
Патчить регулярками? Не удобно, не наглядно, не гарантирует результат. Попробуйте взять этот вьюв, и пропатчить его чем-то более сложным чем просто переименовать переменную. Также, не забудьте о том, что код уже отредактировали пользователи, и он выглядит иначе.
Полная замена строки со старым кодом на новый? Тогда в чем смысл того что он лежал в базе и был доступен на редактирование?
И это при том что вы трижды выстрелили себе в ногу отказавшись от коробочных диффов доступных под контролем версий.
RBAC неудачный пример. DbManager не хранит код в БД, он хранит связи.
Во первых это дело каждого, что и как обновлять, можно при выходе релиза все изменения опять перепаковывать в 1 миграцию, а можно просто не обновлять, если изменения коснулись стилей или разметки. Во вторых для вью можно сделать отдельную бд с внешними подключениями. В третьих я имел ввиду конечно же не «php шаблонизатор», а «смарти» или «твиг». В 4 никто не мешает вам сделать импортер из .twig.php файлов в бд (вы же надеюсь хранение ролей именно так организовываете, при использовании yii\rbac\DbManager? — правите rbac/init команду, а уже она делает логику импорта, будь-то через truncate (если нет fk) или через 'update|replace'.
Не убедительно. Выглядит как усложнение ради усложнения.
Твиг и смарти — такой же частный случай шаблонизаторов как и нативный php.
Такие вещи, если в них действительно есть объективная необходимость, решаются на уровне проекта а не фреймворка.
Твиг и смарти — такой же частный случай шаблонизаторов как и нативный php.
Такие вещи, если в них действительно есть объективная необходимость, решаются на уровне проекта а не фреймворка.
посмотрите метод render, шаблон и файл это разные вещи, называть нужно вещи своими именами, к примеру — renderFile(). Почему вы считаете логичным, что шаблоны обязаны храниться в файлах это лично ваше дело, но я больше солидарен в этом вопросе с популярными «шаблонизаторами»:
Smarty Resources
Twig Loaders
п.с. может для вас в норме вещей использовать стороннюю библиотеку, но ограничить ее функциональность, но для меня это дико.
Smarty Resources
Twig Loaders
п.с. может для вас в норме вещей использовать стороннюю библиотеку, но ограничить ее функциональность, но для меня это дико.
Похоже, вы невнимательно прочли мои комментарии, и сделали неверные выводы из сказанного.
Не «файлы vs база», а «код vs контент». Развернуть тезис?
Далее… Капитан-очевидность утверждает, что:
Если же все-такивы не строите проект «Абстрактный конь в вакууме» объективные причины имеются, то может и вопрос решать стоит на уровне проекта и его технических условий? Вы же сами написали:
Значит уровень проекта. И при этом ожидаете универсальное решение. Упорно долбите в вопрос «Как?» прежде чем ответить «Зачем?». Отсюда и большая часть вашей критики похожа на поверхностное «бла-бла-бла».
Сделайте полезное: сформулируйте свой вопрос, обоснуйте, отпишите в баг-трекер. Комьюнити хорошо реагирует на адекватные идеи.
Не «файлы vs база», а «код vs контент». Развернуть тезис?
Далее… Капитан-очевидность утверждает, что:
- Код под контролем версий, контент — нет.
- Вьюв — неотъемлемая часть кода.
- Сознательный вынос вьюва из под контроля версий без объективных причин — выглядит странно, и обещает проблемы.
- Костыли, которыми это все потом будет синхронизироваться — необоснованное усложнение системы.
Если же все-таки
это дело каждого, что и как обновлять
Значит уровень проекта. И при этом ожидаете универсальное решение. Упорно долбите в вопрос «Как?» прежде чем ответить «Зачем?». Отсюда и большая часть вашей критики похожа на поверхностное «бла-бла-бла».
Сделайте полезное: сформулируйте свой вопрос, обоснуйте, отпишите в баг-трекер. Комьюнити хорошо реагирует на адекватные идеи.
Оффтоп
Да, и не нужно приписывать мне то, чего нет.
Я не утверждал обратного ни по поводу вещей ни по поводу имен.
Не в файлах, а в коде под контролем версий (см. выше).
Не может. Для меня норма — здравый смысл. А он зависит от ситуации.
шаблон и файл это разные вещи, называть нужно вещи своими именами
Я не утверждал обратного ни по поводу вещей ни по поводу имен.
Почему вы считаете логичным, что шаблоны обязаны храниться в файлах это лично ваше дело
Не в файлах, а в коде под контролем версий (см. выше).
может для вас в норме вещей использовать стороннюю библиотеку, но ограничить ее функциональность
Не может. Для меня норма — здравый смысл. А он зависит от ситуации.
Код под контролем версий, контент — нет.
цитату покажите, где я УТВЕРЖДАЛ, а не как из один возможных вариантов решения предложил
Вьюв — неотъемлемая часть кода.и
«код vs контент».
разжуйте свой тезис, а то я уже стал сомневаться, что вы имели ввиду вначале, а позже сами контент называете кодом + я это не утверждал
Сознательный вынос вьюва из под контроля версий без объективных причин — выглядит странно, и обещает проблемы.
так же не утверждал
Костыли, которыми это все потом будет синхронизироваться — необоснованное усложнение системы.
и это не утверждал — вы похоже свои мысли выдаете за мои утверждения
Если же все-таки вы не строите проект «Абстрактный конь в вакууме» объективные причины имеются, то может и вопрос решать стоит на уровне проекта и его технических условий? Вы же сами написали:
Давайте в sfiwt mailer уберем возможность конфигурировать транспорты — пусть решают на уровне проекта! Урежем весь функционал, чего уж мелочиться на шаблонизаторах. Почему нельзя сделать возможным конфигурировать loader — они все под интерфейсом -я лично не вижу проблемы в этом, а вижу хардкор, с которым вы соглашаетесь!
Значит уровень проекта. И при этом ожидаете универсальное решение. Упорно долбите в вопрос «Как?» прежде чем ответить «Зачем?». Отсюда и большая часть вашей критики похожа на поверхностное «бла-бла-бла».
Зачем вы читаете мое «бла-бла-бла» вместо полезной литературы по ООП?
Сделайте полезное: сформулируйте свой вопрос, обоснуйте, отпишите в баг-трекер. Комьюнити хорошо реагирует на адекватные идеи.
опаньки «нежданчик» — смотрим так же на число
— не увидел у вас не одного обоснования почему это должно быть на уровне проекта, вы лишь пытаетесь навязать мне проблемы, которые вы не смогли бы решить в системе контроля версий.
в rbac вам так же лучше не вникать, ну по крайней мере yii\rbac\DbManager, там тоже у вас с системами контроля версий будут проблемы
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
В ожидании Yii2 2.0.4