Comments 17
Отлично рассказано, спасибо. Хотя я Yiinitializer и не использую, но ряд вещей возьму себе на вооружение.
Большую часть своей статьи я написал относительно давно, но никак не доходили руки доделать. Поэтому обновление Yii Boilerplate прошло для меня незамеченным. Сейчас посмотрел и хочу сказать, что выглядит очень вкусно. Однозначно буду пробовать, как минимум для сравнения.
Довольно интересно, что Yii Boilerplate и Yiinitializr развиваются поочерёдно. Как только первый берёт паузу, второй начинаете набирать обороты, и так по кругу. Хотя, конечно, лучше бы они шли нога в ногу, каждый со своими собственными идеями.
Довольно интересно, что Yii Boilerplate и Yiinitializr развиваются поочерёдно. Как только первый берёт паузу, второй начинаете набирать обороты, и так по кругу. Хотя, конечно, лучше бы они шли нога в ногу, каждый со своими собственными идеями.
собственно я тоже не следил. Просто сейчас понадобился скелет для очередного приложения и решил посмотреть, что поменялось — вот и обнаружил, что boilerplate неплохо так обновился.
а развиваются они поочередно, т.к. первая версия boilerplate была по-сути написана теми же людьми, что initializer — 2amigos. Потом они начали уже initializer делать, а boilerplate завис. Вот сейчас его clevertech обновил и по-сути все заново сделали.
а развиваются они поочередно, т.к. первая версия boilerplate была по-сути написана теми же людьми, что initializer — 2amigos. Потом они начали уже initializer делать, а boilerplate завис. Вот сейчас его clevertech обновил и по-сути все заново сделали.
Пользуюсь YiiInitializr, не могли бы вы детальнее остановиться на API
Я не совсем представляю, как может пригодиться API, кроме инициализации приложения. Если вы чуточку развернёте вопрос, то я постараюсь пролить свет на интересующие вас моменты.
Удалено
Выглядит интересно, но не понимаю, почему бы не использовать общие модели для API, backend и frontend? Линки что-ли делать? Ведь в большинстве случаев нужно использовать те же самые модели.
Нет, общие модели кладутся в common/models, к примеру это Users, Addresses и Orders. Во фронте /frontend/models можно кинуть SitePage, AuthForm и т.п. Соответственно всё что в коммоне будет доступно везде, а то что в фронте — только в нем, удобно.
Тоже самое и остальными папками (виджеты, экстеншины, компоненты)
Тоже самое и остальными папками (виджеты, экстеншины, компоненты)
потому что при правильной архитектуре, только API ломится к БД, а модели во фронте и бэке общаются уже через API. ну и вполне нормально если валидация у этих моделей будет иногда отличаться.
EWebApplication
??? Они же вроде решили отказаться от этих префиксов, разве не так?
А почему настройки к БД пишутся в env/dev.php? Этот файл с общими настройками для всей комманды, для запуска приложения на «локали». А вот env.php это уже конкретно каждого файл с настройками (который должен игнорится). верно? и вот в нем нужно писать уникальные конфиги (для каждого разработчика).
Не совсем так. Файл env.php создаётся автоматически (а по идее должен и перезаписываться) в зависимости от окружения. Поэтому в него ничего писать не нужно, а то при обновлении все ваши настройки потеряются. Для локальной конфигурации предполагается использование файла
/<part>/config/local.php, который также должен быть исключён в Git, и в который уже можно спокойно писать свои уникальные настройки.Sign up to leave a comment.
Большое руководство по Yiinitializr