Большое руководство по Yiinitializr

[Ekstazi]

Отлично рассказано, спасибо. Хотя я Yiinitializer и не использую, но ряд вещей возьму себе на вооружение.

[jarosluv]

Благодарю за оценку. Рад, что вы смогли найти для себя что-то полезное :)

[plandem]

После совсем недавнего обновления — мой выбор Yii Boilerplate: github.com/clevertech/YiiBoilerplate

[jarosluv]

Большую часть своей статьи я написал относительно давно, но никак не доходили руки доделать. Поэтому обновление Yii Boilerplate прошло для меня незамеченным. Сейчас посмотрел и хочу сказать, что выглядит очень вкусно. Однозначно буду пробовать, как минимум для сравнения.

Довольно интересно, что Yii Boilerplate и Yiinitializr развиваются поочерёдно. Как только первый берёт паузу, второй начинаете набирать обороты, и так по кругу. Хотя, конечно, лучше бы они шли нога в ногу, каждый со своими собственными идеями.

[plandem]

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

а развиваются они поочередно, т.к. первая версия boilerplate была по-сути написана теми же людьми, что initializer — 2amigos. Потом они начали уже initializer делать, а boilerplate завис. Вот сейчас его clevertech обновил и по-сути все заново сделали.

[Actor]

Пользуюсь YiiInitializr, не могли бы вы детальнее остановиться на API

[jarosluv]

Я не совсем представляю, как может пригодиться API, кроме инициализации приложения. Если вы чуточку развернёте вопрос, то я постараюсь пролить свет на интересующие вас моменты.

[Actor]

В Advanced шаблоне есть возможность предоставлять API, интересует как там реализована авторизация и т.п., можно на примере разработки под фронтент.

[jarosluv]

Изначально я не правильно вас понял. Про API действительно стоило упомянуть, но т. к. в действии я его не испытывал, то совершенно забыл это сделать. Постараюсь сегодня дописать ещё раздел в статью про API в Advanced шаблоне.

[Actor]

Удалено

[dimitrymd]

Выглядит интересно, но не понимаю, почему бы не использовать общие модели для API, backend и frontend? Линки что-ли делать? Ведь в большинстве случаев нужно использовать те же самые модели.

[Actor]

Нет, общие модели кладутся в common/models, к примеру это Users, Addresses и Orders. Во фронте /frontend/models можно кинуть SitePage, AuthForm и т.п. Соответственно всё что в коммоне будет доступно везде, а то что в фронте — только в нем, удобно.

Тоже самое и остальными папками (виджеты, экстеншины, компоненты)

[plandem]

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

[uaoleg]

EWebApplication

??? Они же вроде решили отказаться от этих префиксов, разве не так?

[jarosluv]

В статье идёт речь о первой версии Yii Framework. Во второй версии действительно вместо префиксов используются пространства имён.

[DenisOgr]

А почему настройки к БД пишутся в env/dev.php? Этот файл с общими настройками для всей комманды, для запуска приложения на «локали». А вот env.php это уже конкретно каждого файл с настройками (который должен игнорится). верно? и вот в нем нужно писать уникальные конфиги (для каждого разработчика).

[jarosluv]

Не совсем так. Файл env.php создаётся автоматически (а по идее должен и перезаписываться) в зависимости от окружения. Поэтому в него ничего писать не нужно, а то при обновлении все ваши настройки потеряются. Для локальной конфигурации предполагается использование файла /<part>/config/local.php, который также должен быть исключён в Git, и в который уже можно спокойно писать свои уникальные настройки.