Pull to refresh

Comments 17

Отлично рассказано, спасибо. Хотя я Yiinitializer и не использую, но ряд вещей возьму себе на вооружение.
Благодарю за оценку. Рад, что вы смогли найти для себя что-то полезное :)
Большую часть своей статьи я написал относительно давно, но никак не доходили руки доделать. Поэтому обновление Yii Boilerplate прошло для меня незамеченным. Сейчас посмотрел и хочу сказать, что выглядит очень вкусно. Однозначно буду пробовать, как минимум для сравнения.

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

а развиваются они поочередно, т.к. первая версия boilerplate была по-сути написана теми же людьми, что initializer — 2amigos. Потом они начали уже initializer делать, а boilerplate завис. Вот сейчас его clevertech обновил и по-сути все заново сделали.
Пользуюсь YiiInitializr, не могли бы вы детальнее остановиться на API
Я не совсем представляю, как может пригодиться API, кроме инициализации приложения. Если вы чуточку развернёте вопрос, то я постараюсь пролить свет на интересующие вас моменты.
В Advanced шаблоне есть возможность предоставлять API, интересует как там реализована авторизация и т.п., можно на примере разработки под фронтент.
Изначально я не правильно вас понял. Про API действительно стоило упомянуть, но т. к. в действии я его не испытывал, то совершенно забыл это сделать. Постараюсь сегодня дописать ещё раздел в статью про API в Advanced шаблоне.
Выглядит интересно, но не понимаю, почему бы не использовать общие модели для API, backend и frontend? Линки что-ли делать? Ведь в большинстве случаев нужно использовать те же самые модели.
Нет, общие модели кладутся в common/models, к примеру это Users, Addresses и Orders. Во фронте /frontend/models можно кинуть SitePage, AuthForm и т.п. Соответственно всё что в коммоне будет доступно везде, а то что в фронте — только в нем, удобно.

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

??? Они же вроде решили отказаться от этих префиксов, разве не так?
В статье идёт речь о первой версии Yii Framework. Во второй версии действительно вместо префиксов используются пространства имён.
А почему настройки к БД пишутся в env/dev.php? Этот файл с общими настройками для всей комманды, для запуска приложения на «локали». А вот env.php это уже конкретно каждого файл с настройками (который должен игнорится). верно? и вот в нем нужно писать уникальные конфиги (для каждого разработчика).
Не совсем так. Файл env.php создаётся автоматически (а по идее должен и перезаписываться) в зависимости от окружения. Поэтому в него ничего писать не нужно, а то при обновлении все ваши настройки потеряются. Для локальной конфигурации предполагается использование файла /<part>/config/local.php, который также должен быть исключён в Git, и в который уже можно спокойно писать свои уникальные настройки.
Only those users with full accounts are able to leave comments. Log in, please.