<rmcreative>

RSS

С Yii 1.1 на Yii 2.0, часть 3: приложения

13 января 2015

В 1.1 был только один шаблон приложения, который можно было развернуть через yiic webapp после того, как вы скачаете сам фреймворк. Команда копировала шаблон приложения из директории фреймворка в указанную вами директорию.

В 2.0 шаблоны, как и всё остальное, ставятся через Composer. Ничего предварительно скачивать не нужно. Команда напоминает команду из 1.1, разве что указывается из какого пакета ставить шаблон:

composer global require "fxp/composer-asset-plugin:1.0.0"
composer create-project --prefer-dist yiisoft/yii2-app-basic my/dir/basic

Стандартных шаблона два: basic и advanced. Есть возможность делать свои. Например, я сделал minimal. Начать изучение фреймворка лучше с basic. Это не значит, что данный шаблон чем-то хуже advanced, просто он больше похож на 1.1:

assets — классы-конфиги asset-ов
commands — консольные команды
config — конфиги
controllers — контроллеры
mail — шаблоны для писем
models — модели
runtime — логи и другие временные данные
tests — тесты
vendor — зависимости, вытягиваются Composer-ом
views — шаблоны для веб
web — вебрут
    assets — уже опубликованные asset-ы
    index.php — входной файл
./yii — входной файл для консольного приложения, аналог yiic из 1.1

Присутствуют директории, которых в 1.1 не было: assets, mail, vendor. Assets хранит классы, описывающие подключение CSS и JavaScript для веб-приложения. В mail хранятся шаблоны для писем, vendor заполняется Composer-ом и лезть туда руками не стоит.

Некоторые директории из 1.1 отсутствуют. Стоит отметить components, extensions, messages и migrations. Директория extensions более не нужна. Расширения ставятся через Composer и автоматически попадают в vendor. messages и migrations автоматически создаются по мере необходимости. В components нет нужды. В 2.0 можно раскладывать классы в любые директории. Они будут загружаться автоматически, если их namespace соответствует. Если вам без components не уютно, можно создать.

Ещё одним важным отличием от 1.1 является то, что index.php располагается не в корне приложения, а в директории web. То есть в качестве webroot надо указывать именно директорию web. Весь код при этом не будет видно через веб, что более безопасно. В 1.1 приходилось делать подобную структуру вручную каждый раз.

Реструктуризация создаёт некоторые проблемы на shared-хостинге. Если вам можно загружать файлы выше webroot, достаточно переименовать web в название webroot на вашем сервере. Если загружать выше webroot нельзя (что не очень часто), придётся переложить index.php на уровень выше и поправить в нём пути. То есть фактически привести всё к 1.1.

Advanced отличается тем, что разделяет код на несколько приложений, каждое со своим входным файлом в расчёте на несколько доменов. Окружения реализованы через локальные конфиги. Также в нём имеется готовая регистрация и восстановление пароля и готовая модель User, привязанная к базе данных. Всё это описано в руководстве. В остальном шаблоны схожи.

← С Yii 1.1 на Yii 2.0, часть 2: Composer

Комментарии RSS

  1. №9562
    Костя
    Костя 13 янв. 2015 г., 9:30:03

    @samdark, мне кажется, что стоит все таки написать один пост-рекомендацию про складывание своих классов в yii2 приложении. Как раз здесь упомянул про components, хотя с другой стороны про неуютность и делайте по привычке, по моему лучше так не говорить :) Форуме люди тоже в components по дефолту складывают и ActiveRecord, и Controller. Будут туда же складывать Query, Mailer, FooBar. И в итоге получится куча мусора и неразберихи в одном неймспейсе, а в последствии и в проекте.

  2. №9571
    Максим
    Максим 14 янв. 2015 г., 10:42:21

    Спасибо.

  3. №9573
    bob
    bob 14 янв. 2015 г., 14:38:24

    Спасибо большое!

  4. №9574
    Sam
    Sam 14 янв. 2015 г., 18:18:38

    Костя, напишу.

  5. №9576
    Денис
    Денис 14 янв. 2015 г., 19:23:35

    А каким будет самый феншуйный способ складывать на одном домене фронт и админку?

    Вспоминая несколько подходов в YII 1.x:

    • модульный
    • WebApplicationEnd behavior
    • yiinitializr

    Интересно узнать как теперь обстоит вопрос.

  6. №9577
    Sam
    Sam 14 янв. 2015 г., 20:38:45

    Наверное, модулями.

  7. №9597
    Александр
    Александр 03 февр. 2015 г., 1:52:10

    Продолжу вопрос Дениса. Правила валидации моделей для backend/frontend делать через сценарии или наследование от базовой модели с переопределением rules?

  8. №10016
    Red
    Red 07 окт. 2015 г., 21:22:32

    В зависимости от количества полей у модели.

    При большом количестве полей которые могут валидироваться по различным сценариям ваши rules() могут легко превратиться в полотно кода. В то время как используя сценарии при более тонких моделях вы избегаете создания лишних классов и файлов состоящих из нескольких строчек.

  1. Почта опубликована не будет.

  2. Можно использовать синтаксис Markdown или HTML.

  3. Введите ответ в поле. Щёлкните, чтобы получить другую задачу.