С 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
, привязанная к базе данных. Всё это описано в руководстве. В остальном шаблоны схожи.
Комментарии RSS по email OK
@samdark, мне кажется, что стоит все таки написать один пост-рекомендацию про складывание своих классов в yii2 приложении. Как раз здесь упомянул про components, хотя с другой стороны про неуютность и делайте по привычке, по моему лучше так не говорить :) Форуме люди тоже в components по дефолту складывают и ActiveRecord, и Controller. Будут туда же складывать Query, Mailer, FooBar. И в итоге получится куча мусора и неразберихи в одном неймспейсе, а в последствии и в проекте.
Спасибо.
Спасибо большое!
Костя, напишу.
А каким будет самый феншуйный способ складывать на одном домене фронт и админку?
Вспоминая несколько подходов в YII 1.x:
Интересно узнать как теперь обстоит вопрос.
Наверное, модулями.
Продолжу вопрос Дениса. Правила валидации моделей для backend/frontend делать через сценарии или наследование от базовой модели с переопределением rules?
В зависимости от количества полей у модели.
При большом количестве полей которые могут валидироваться по различным сценариям ваши rules() могут легко превратиться в полотно кода. В то время как используя сценарии при более тонких моделях вы избегаете создания лишних классов и файлов состоящих из нескольких строчек.