я настройки подключений, всякие секреты апи и прочее не храню в конфигах окружения, те что попадают в репозиторий, для этого есть специальные local файлы
цитату покажите, где я УТВЕРЖДАЛ, а не как из один возможных вариантов решения предложил
Вьюв — неотъемлемая часть кода.
и
«код vs контент».
разжуйте свой тезис, а то я уже стал сомневаться, что вы имели ввиду вначале, а позже сами контент называете кодом + я это не утверждал
Сознательный вынос вьюва из под контроля версий без объективных причин — выглядит странно, и обещает проблемы.
так же не утверждал
Костыли, которыми это все потом будет синхронизироваться — необоснованное усложнение системы.
и это не утверждал — вы похоже свои мысли выдаете за мои утверждения
Если же все-таки вы не строите проект «Абстрактный конь в вакууме» объективные причины имеются, то может и вопрос решать стоит на уровне проекта и его технических условий? Вы же сами написали:
Давайте в sfiwt mailer уберем возможность конфигурировать транспорты — пусть решают на уровне проекта! Урежем весь функционал, чего уж мелочиться на шаблонизаторах. Почему нельзя сделать возможным конфигурировать loader — они все под интерфейсом -я лично не вижу проблемы в этом, а вижу хардкор, с которым вы соглашаетесь!
Значит уровень проекта. И при этом ожидаете универсальное решение. Упорно долбите в вопрос «Как?» прежде чем ответить «Зачем?». Отсюда и большая часть вашей критики похожа на поверхностное «бла-бла-бла».
Зачем вы читаете мое «бла-бла-бла» вместо полезной литературы по ООП?
Сделайте полезное: сформулируйте свой вопрос, обоснуйте, отпишите в баг-трекер. Комьюнити хорошо реагирует на адекватные идеи.
— не увидел у вас не одного обоснования почему это должно быть на уровне проекта, вы лишь пытаетесь навязать мне проблемы, которые вы не смогли бы решить в системе контроля версий.
посмотрите метод render, шаблон и файл это разные вещи, называть нужно вещи своими именами, к примеру — renderFile(). Почему вы считаете логичным, что шаблоны обязаны храниться в файлах это лично ваше дело, но я больше солидарен в этом вопросе с популярными «шаблонизаторами»:
1. зависимость должна описываться интерфейсом (опять смотрим, как это реализовано в доктрине), пусть даже через контейнер, чтото похожее на это.
2. привык верить $model->classname()
3. в вашем варианте или в контроллере обращаться к контейнеру или же обращаться к модели через статику, в которой будет спрятана эта логика по созданию объекта из контейнера
4. в контроллере появится запись вида
Если вы решили «домашку», попробуйте решить ее снова, но не перекрывая обе модели из модулей.
для 2 модели нужна обратная связь и 2 модель тоже надо расширять.
значит модуль не самодостаточен? надо регистрировать модель в контейнере прежде чем использовать модуль? в чем преимущество такого модуля для обычного пользователя (не программиста)?
2. не вижу смысла в
public $className = 'UserModelCustom';
3. ваш вариант подразумевает создание модели через контейнер в контроллере, ну или как минимум в статическом методе модели `MyModel::create()`
4. Вернемся к нашим ActiveRecord и ActiveQuery, теперь помимо того, что ActiveQuery и так был завязан на класс модели, мы его завязываем уже на объект, т.е. чтобы использовать !ActiveQuery! нам нужно создать новый ActiveRecord — вы до сих пор не видите тут проблему? И еще учтите что di контейнер не создает объект при каждом обращении, а передает ранее созданный объект (сервис) по ссылке!
Еще раз повторю — перечитайте хаб, там все есть и даже есть пример из симфони, как это реализовано там.
Есть такая поговорка — «замахнулся — бей» у вас пока только пустые слова.
Напишите, как связать модели из разных модулей, не надо придумывать расширения, которые якобы создают модели через di контейнер — это не возможно на коробочном ActiveRelationTrait
конечно поведение уже написано и находится в пакете yii2, но все же отпишусь:
1. автору явно надо почитать про оптимизацию, а конкретно в данном случае:
2. если вы в owner модели перекрыли метод find, к примеру так
public static function find()
{
return parent::find()->andWhere(['status' => 'public']);
}
то расширение удалит условие установленное в перекрытом методе, что делает потенциально опасным применение данного поведения. Решение заменить where на andWhere
Вы или уже троллите или просто пытаетесь спровоцировать меня на какие то грубости, увидев выше, что сообщество плюсует вас и минусует меня по аналогичным провокациям.
Во первых это дело каждого, что и как обновлять, можно при выходе релиза все изменения опять перепаковывать в 1 миграцию, а можно просто не обновлять, если изменения коснулись стилей или разметки. Во вторых для вью можно сделать отдельную бд с внешними подключениями. В третьих я имел ввиду конечно же не «php шаблонизатор», а «смарти» или «твиг». В 4 никто не мешает вам сделать импортер из .twig.php файлов в бд (вы же надеюсь хранение ролей именно так организовываете, при использовании yii\rbac\DbManager? — правите rbac/init команду, а уже она делает логику импорта, будь-то через truncate (если нет fk) или через 'update|replace'.
связь моделей не будет работать через di, через контейнер работают только объекты создающиеся через Yii::createObject(), а то что создается через new ArModel надо перекрывать через classMap, что не позволит унаследоваться от одноименного класса, как это делало поведение в di контейнере, что опять же повторюсь, является больше странным поведением, чем фишкой.
цитату покажите, где я УТВЕРЖДАЛ, а не как из один возможных вариантов решения предложил
и
разжуйте свой тезис, а то я уже стал сомневаться, что вы имели ввиду вначале, а позже сами контент называете кодом + я это не утверждал
так же не утверждал
и это не утверждал — вы похоже свои мысли выдаете за мои утверждения
Давайте в sfiwt mailer уберем возможность конфигурировать транспорты — пусть решают на уровне проекта! Урежем весь функционал, чего уж мелочиться на шаблонизаторах. Почему нельзя сделать возможным конфигурировать loader — они все под интерфейсом -я лично не вижу проблемы в этом, а вижу хардкор, с которым вы соглашаетесь!
Зачем вы читаете мое «бла-бла-бла» вместо полезной литературы по ООП?
опаньки «нежданчик» — смотрим так же на число
— не увидел у вас не одного обоснования почему это должно быть на уровне проекта, вы лишь пытаетесь навязать мне проблемы, которые вы не смогли бы решить в системе контроля версий.
Smarty Resources
Twig Loaders
п.с. может для вас в норме вещей использовать стороннюю библиотеку, но ограничить ее функциональность, но для меня это дико.
2. привык верить $model->classname()
3. в вашем варианте или в контроллере обращаться к контейнеру или же обращаться к модели через статику, в которой будет спрятана эта логика по созданию объекта из контейнера
4. в контроллере появится запись вида
в 4 пункте это и есть свой костыль из подручных средств, что не прозрачно и человеку поддерживаемому код можно заработать опухоль мозга
для 2 модели нужна обратная связь и 2 модель тоже надо расширять.
значит модуль не самодостаточен? надо регистрировать модель в контейнере прежде чем использовать модуль? в чем преимущество такого модуля для обычного пользователя (не программиста)?
2. не вижу смысла в
3. ваш вариант подразумевает создание модели через контейнер в контроллере, ну или как минимум в статическом методе модели `MyModel::create()`
4. Вернемся к нашим ActiveRecord и ActiveQuery, теперь помимо того, что ActiveQuery и так был завязан на класс модели, мы его завязываем уже на объект, т.е. чтобы использовать !ActiveQuery! нам нужно создать новый ActiveRecord — вы до сих пор не видите тут проблему? И еще учтите что di контейнер не создает объект при каждом обращении, а передает ранее созданный объект (сервис) по ссылке!
Есть такая поговорка — «замахнулся — бей» у вас пока только пустые слова.
Напишите, как связать модели из разных модулей, не надо придумывать расширения, которые якобы создают модели через di контейнер — это не возможно на коробочном ActiveRelationTrait
1. автору явно надо почитать про оптимизацию, а конкретно в данном случае:
лучше юзать count()
2. если вы в owner модели перекрыли метод find, к примеру так
то расширение удалит условие установленное в перекрытом методе, что делает потенциально опасным применение данного поведения. Решение заменить where на andWhere
—
p.s. по этой же причине нельзя создавать модели через контейнер
отказываетесь от них? я вам 10 раз уже повторил конкретный пример, который написан в хабе.
и объяснил, что с моделями не получилось в этом комментарии habrahabr.ru/post/254179/#comment_8360471
Вы или уже троллите или просто пытаетесь спровоцировать меня на какие то грубости, увидев выше, что сообщество плюсует вас и минусует меня по аналогичным провокациям.
>Конкретно тупиковая ситуация — связь моделей