Полное руководство по yii 2.0

Содержание

Настройка PHP-окружения ¶

Для работы с большей частью функций интернационализации Yii использует PHP-расширение intl. Например, это расширение используют классы, отвечающие за форматирование чисел и дат yii\i18n\Formatter и за форматирование строк yii\i18n\MessageFormatter. Оба класса поддерживают базовый функционал даже в том случае, если расширение не установлено. Однако, этот запасной вариант более-менее будет работать только для сайтов на английском языке, хотя даже для них большая часть широких возможностей расширения не будет доступна, поэтому его установка настоятельно рекомендуется.

PHP-расширение intl основано на библиотеке ICU, которая описывает правила форматирования для различных локалей. Поэтому следует помнить, что форматирование чисел и дат вместе с синтаксисом форматирования может отличаться в зависимости от версии библиотеки ICU, которая была скомпилирована в вашем дистрибутиве PHP.

Чтобы сайт работал одинаково во всех окружениях, рекомендуется устанавливать одинаковую версию расширения intl, при этом удостоверяясь, что везде используется одинаковая версия библиотеки ICU.

Чтобы узнать, какая версия ICU используется текущим PHP интерпретатором, используйте следующий скрипт:


Чтобы иметь доступ ко всем возможностям, описанным в документации, мы рекомендуем использовать ICU версии 49 или новее. В более ранних версиях отсутствует указатель в правилах склонений. На сайте http://site.icu-project.org/download вы можете ознакомиться со списком доступных версий ICU

Обратите внимание, что схема нумерации версий изменилась после версии 4.8 и последовательность версий выглядит так: ICU 4.8, ICU 49, ICU 50, ICU 51 и так далее

Действия ¶

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

Следующий пример показывает контроллер с двумя действиями: и :

В действии (определенном методом ), код сначала загружает модель согласно запрошенному ID модели; Если модель успешно загружена, то код отобразит ее с помощью представления под названием . В противном случае будет брошено исключение.

В действии (определенном методом ), код аналогичен. Он сначала пытается загрузить модель с помощью данных из запроса и сохранить модель. Если все прошло успешно, то код перенаправляет браузер на действие с ID только что созданной модели. В противном случае он отобразит представление , через которое пользователь может заполнить нужные данные.

Жизненный цикл приложения ¶

Когда входной скрипт выполняется для обработки запроса, приложение будет развиваться согласно следующему жизненному циклу:

  1. Входной скрипт загружает конфигурацию приложения в качестве массива;
  2. Входной скрипт создаёт новый объект приложения:
    • Вызывается метод , который настраивает некоторые жизненно важные свойства приложения, такие как ;
    • Регистрируется ;
    • Настраиваются свойства приложения;
    • Вызывается метод , который затем вызывает метод для начальной загрузки компонентов.
  3. Входной скрипт вызывает метод для запуска приложения:
    • Возникает событие ;
    • Обработка запроса: разбор информации запроса в маршрут с соответствующими параметрами; создание объектов модуля, контроллера и действия согласно указанному маршруту; запуск действия;
    • Возникает событие ;
    • Ответ отсылается конечному пользователю.
  4. Входной скрипт получает значение статуса выхода от приложения и заканчивает обработку запроса.

Входные скрипты

Компоненты приложения

Found a typo or you think this page needs improvement?Edit it on github !

Установка при помощи Composer ¶

Установка Composer

Если Composer еще не установлен это можно сделать по инструкции на getcomposer.org, или одним из нижеперечисленных способов. На Linux или Mac используйте следующую команду:

На Windows, скачайте и запустите Composer-Setup.exe.

В случае возникновения проблем читайте раздел «Troubleshooting» в документации Composer. Если вы только начинаете использовать Composer, рекомендуем прочитать как минимум раздел «Basic usage».

В данном руководстве предполагается, что Composer установлен . То есть он доступен через команду . Если вы используете из локальной директории, изменяйте команды соответственно.

Если у вас уже установлен Composer, обновите его при помощи .

После установки Composer устанавливать Yii можно запустив следующую команду в папке доступной через веб:

Установка Yii

Эта команда устанавливает последнюю стабильную версию Yii в директорию . Если хотите, можете выбрать другое имя директории.

Active Record ¶

В Yii 2.0 внесено множество изменений в работу Active Record. Два основных из них включают в себя построение запросов и работу со связями.

Класс версии 1.1 был заменен yii\db\ActiveQuery. Этот класс наследуется от yii\db\Query и таким образом получает все методы, необходимые для построения запроса. Чтобы начать строить запрос следует вызвать метод :

Для объявления связи следует просто объявить геттер, который возвращает объект ActiveQuery. Имя свойства, определённое геттером, представляет собой название связи. Например, следующий код объявляет связь (в версии 1.1, вам нужно было бы объявить связи в одном месте — методе ):

Теперь вы можете использовать выражение для получения всех заказов клиента из связанной таблицы. Вы также можете использовать следующий код, чтобы применить нужные условия «на лету»:

Yii 2.0 осуществляет жадную загрузку связи не так, как это было в 1.1. В частности, в версии 1.1 для выбора данных из основной и связанной таблиц будет использован запрос JOIN. В Yii 2.0 будут выполнены два запроса без использования JOIN: первый запрос возвращает данные для основной таблицы, а второй, осуществляющий фильтрацию по первичным ключами основной таблицы — для связанной.

Вместо того, чтобы при выборке большого количества записей возвращать объекты ActiveRecord, вы можете использовать в построении запроса метод . Это заставит вернуть результат запроса в виде массива, что при большом количестве записей может существенно снизить затрачиваемое процессорное время и объём потребляемой памяти. Например:

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

Также в версии 1.1 были некоторые проблемы с переопределением конструктора ActiveRecord. Данные проблемы отсутствуют в версии 2.0

Обратите внимание, что при добавлении параметров в конструктор, вам, возможно, понадобится переопределить метод

Существует также множество других улучшений в ActiveRecord. Подробнее о них можно узнать в разделе «Active Record».

Структура приложения

Yii-приложения организованы по MVC шаблону проектирования. Модели — это данные, бизнес-логика и бизес-правила. Представления отвечают за отображение информации. Контроллеры принимают входные данные от пользователя и преобразуют их в понятный для моделей формат и команды, также отвечают за отображение нужного представления.

Входные скрипты

Это первое звено в процессе начальной загрузки приложения. Входные скрипты для веб-приложений — index.php, для консольных приложений — yii.php

Приложения

Приложения это объекты, которые управляют всей структурой и жизненным циклом прикладной системы Yii. Во входном скрипте создаётся один объект приложения и он доступен глобально через . Существуют 2 вида приложений — веб-приложения и консольные приложения. Первые занимаются обработкой веб-запросов, вторые — консольных команд. Входной скрипт при создании приложения, загружает конфигурацию и применяет её к приложению.

  • Компоненты приложения
  • Контроллеры
  • Модели
  • Представления
  • Модули
  • Фильтры
  • Виджеты
  • Ресурсы
  • Расширения

Базовые расширения ¶

Yii предоставляет следующие базовые расширения, (или «Official Extensions») которые разрабатывает и поддерживает команда разработчиков Yii. Они все зарегистрированы на Packagist и могут быть легко установлены, как описано в подразделе .

  • yiisoft/yii2-apidoc: предоставляет расширяемый и высокопроизводительный генератор документации API. Оно также используется для генерации документации API фреймворка.
  • yiisoft/yii2-authclient: предоставляет набор наиболее часто используемых клиентов авторизации, таких, как Facebook OAuth2 клиент и GitHub OAuth2 клиент.
  • yiisoft/yii2-bootstrap: предоставляет набор виджетов, которые являются компонентами и плагинами Bootstrap.
  • yiisoft/yii2-codeception (deprecated): предоставляет поддержку тестирования, основанного на Codeception.
  • yiisoft/yii2-debug: предоставляет поддержку отладки в приложениях Yii. Когда это расширение используется, отладочная панель появится в нижней части каждой страницы. Это расширение также предоставляет набор отдельных страниц для отображения более подробной отладочной информации.
  • yiisoft/yii2-elasticsearch: предоставляет поддержку использования Elasticsearch. Оно включает в себя поддержку основных поисковых запросов, а также реализует шаблон проектирования Active Record, который позволяет хранить записи Active Record в Elasticsearch.
  • yiisoft/yii2-faker: предоставляет поддержку использования Faker для генерации фиктивных данных.
  • yiisoft/yii2-gii: предоставляет веб-интерфейс для генерации кода, который является весьма расширяемым и может быть использован для быстрой генерации моделей, форм, модулей, CRUD и т.д.
  • yiisoft/yii2-httpclient: предоставляет HTTP клиент.
  • yiisoft/yii2-imagine: предоставляет часто используемые функции для работы с изображениями, основанные на библиотеке Imagine.
  • yiisoft/yii2-jui: предоставляет набор виджетов, основанный на взаимодействиях и виджетах JQuery UI.
  • yiisoft/yii2-mongodb: предоставляет поддержку использования MongoDB. Оно включает такие возможности, как базовые запросы, Active Record, миграции, кэширование, генерация кода и т.д.
  • yiisoft/yii2-redis: предоставляет поддержку использования redis. Оно включает такие возможности, как базовые запросы, Active Record, кэширование и т.д.
  • yiisoft/yii2-smarty: предоставляет шаблонизатор, основанный на Smarty.
  • yiisoft/yii2-sphinx: предоставляет поддержку использования Sphinx. Оно включает такие возможности, как базовые запросы, Active Record, генерация кода и т.д.
  • yiisoft/yii2-swiftmailer: предоставляет возможности отправки email, основанные на swiftmailer.
  • yiisoft/yii2-twig: предоставляет шаблонизатор, основанный на Twig.

Ресурсы

Обработка запросов: Обзор

Found a typo or you think this page needs improvement?Edit it on github !

Как избежать CSRF ¶

CSRF — это аббревиатура для межсайтинговой подмены запросов. Идея заключается в том, что многие приложения предполагают, что запросы, приходящие от браузера, отправляются самим пользователем. Это может быть неправдой.

Например, сайт имеет URL , который, используя простой GET, разлогинивает пользователя. Пока это запрос выполняется самим пользователем — всё в порядке, но в один прекрасный день злоумышленники размещают код на форуме с большой посещаемостью. Браузер не делает никаких отличий между запросом изображения и запросом страницы, так что когда пользователь откроет страницу с таким тегом , браузер отправит GET запрос на указанный адрес, и пользователь будет разлогинен.

Вот основная идея. Можно сказать, что в разлогировании пользователя нет ничего серьёзного, но с помощью этой уязвимости, можно выполнять опасные операции. Представьте, что существует страница http://an.example.com/purse/transfer?to=anotherUser&amount=2000, обращение к которой с помощью GET запроса, приводит к перечислению 2000 единиц валюты со счета авторизированного пользователя на счет пользователя с логином anotherUser. Учитывая, что браузер для загрузки контента отправляет GET запросы, можно подумать, что разрешение на выполнение такой операции только POST запросом на 100% обезопасит от проблем. К сожалению, это не совсем правда. Учитывайте, что вместо тега , злоумышленник может внедрить JavaScript код, который будет отправлять нужные POST запросы на этот URL.

Для того, чтоб избежать CSRF вы должны всегда:

  1. Следуйте спецификациям HTTP, например запрос GET не должен менять состояние приложения.
  2. Держите защиту CSRF в Yii включенной.

Требования к ПО и знаниям ¶

Yii 2.0 требует PHP 5.4.0 и выше и наилучшим образом работает на последней версии PHP 7. Чтобы узнать требования для отдельных возможностей вы можете запустить скрипт проверки требований, который поставляется с каждым релизом фреймворка.

Для разработки на Yii потребуется общее понимание ООП, так как фреймворк полностью следует этой парадигме. Также стоит изучить такие современные возможности PHP как пространства имён и трейты. Понимание этих концепций позволит вам более легко освоиться c Yii 2.0.

Обновление с версии 1.1

Found a typo or you think this page needs improvement?Edit it on github !

Сравнение Yii с другими фреймворками ¶

Если вы уже знакомы с другими фреймворками, вам наверняка будет интересно сравнить их с Yii.

  • Как и многие другие PHP фреймворки, для организации кода Yii использует архитектурный паттерн MVC (Model-View-Controller).
  • Yii придерживается философии простого и элегантного кода, не пытаясь усложнять дизайн только ради следования каким-либо шаблонам проектирования.
  • Yii является full-stack фреймворком и включает в себя проверенные и хорошо зарекомендовавшие себя возможности, такие как ActiveRecord для реляционных и NoSQL баз данных, поддержку REST API, многоуровневое кэширование и другие.
  • Yii отлично расширяем. Вы можете настроить или заменить практически любую часть основного кода. Используя архитектуру расширений, легко делиться кодом или использовать код сообщества.
  • Одна из главных целей Yii – производительность.

Yii — не проект одного человека. Он поддерживается и развивается сильной командой и большим сообществом разработчиков, которые ей помогают. Авторы фреймворка следят за тенденциями веб-разработки и развитием других проектов. Наиболее подходящие возможности и лучшие практики регулярно внедряются в фреймворк в виде простых и элегантных интерфейсов.

Генерация класса Active Record ¶

Чтобы использовать Gii для генерации класса Active Record, выберите «Генератор модели» (нажав на ссылку на главной странице Gii). И заполните форму следующим образом:

  • Имя таблицы:
  • Класс модели :

Затем нажмите на кнопку «Предварительный просмотр». Вы увидите, что перечислен в результатах создаваемых файлов классов. Вы можете нажать на имя файла класса для просмотра его содержимого.

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


Для перезаписи существующего файла установите флажок рядом с «overwrite» и нажмите кнопку «Generate». Для создания нового файла вы можете просто нажать «Generate».

После этого вы увидите страницу подтверждения, указывающую на то, что код был успешно сгенерирован. Если файл существовал до этого, вы также увидите сообщение о том, что он был перезаписан заново сгенерированным кодом.

Фильтры контроля доступа #

Фильтры контроля доступа (ACF) являются простым методом, который лучше всего использовать в приложениях с простым контролем доступа. Как видно из их названия, ACF — это фильтры, которые могут присоединяться к контроллеру или модулю как поведение. ACF проверяет набор , чтобы убедиться, что пользователь имеет доступ к запрошенному действию.

Код ниже показывает, как использовать ACF фильтр, реализованный в yii\filters\AccessControl:

Код выше показывает ACF фильтр, связанный с контроллером через поведение. Это типичный способ использования фильтров действий. Параметр указывает, что фильтр ACF нужно применять только к действиям , и . Параметр задаёт правила доступа, которые означают следующее:

  • Разрешить всем гостям (ещё не прошедшим авторизацию) доступ к действиям и . Опция содержит знак вопроса , это специальный токен обозначающий «гостя».
  • Разрешить аутентифицированным пользователям доступ к действию . Символ — это другой специальный токен, обозначающий аутентифицированного пользователя.

Когда фильтр ACF проводит проверку авторизации, он проверяет правила по одному сверху вниз, пока не найдёт совпадение. Значение опции выбранного правила указывает, авторизовывать пользователя или нет. Если ни одно из правил не совпало, то пользователь считается НЕавторизованным, и фильтр ACF останавливает дальнейшее выполнение действия.

По умолчанию, когда у пользователя отсутствует доступ к текущему действию, ACF делает следующее:

  • Если пользователь гость, вызывается , который перенаправляет браузер на страницу входа.
  • Если пользователь авторизован, генерируется исключение yii\web\ForbiddenHttpException.

Вы можете переопределить это поведение, настроив свойство :

Правила доступа поддерживают набор свойств. Ниже дано краткое описание поддерживаемых опций. Вы также можете расширить yii\filters\AccessRule, чтобы создать свой собственный класс правил доступа.

  • : задаёт какое это правило, «allow» или «deny».

  • : задаёт действия, соответствующие этому правилу. Значение должно быть массивом идентификаторов действий. Сравнение — регистрозависимо. Если свойство пустое или не задано, то правило применяется ко всем действиям.

  • : задаёт контроллеры, которым соответствует правило. Значение должно быть массивом с идентификаторами контроллеров. Сравнение регистрозависимо. Если свойство пустое или не задано, то правило применяется ко всем контроллерам.

  • : задаёт роли пользователей, соответствующих этому правилу. Распознаются две специальные роли, которые проверяются с помощью :

    • : соответствует гостевому пользователю (не аутентифицирован),
    • : соответствует аутентифицированному пользователю.

    Использование других имён ролей будет приводить к вызову метода , который требует включения RBAC (будет описано дальше). Если свойство пустое или не задано, то правило применяется ко всем ролям.

  • : задаёт , для которых применяется это правило. IP адрес может содержать в конце, так чтобы он соответствовал IP адресу с таким же префиксом. Для примера, ‘192.168.*’ соответствует всем IP адресам в сегменте ‘192.168.’. Если свойство пустое или не задано, то правило применяется ко всем IP адресам.

  • : задаёт http метод (например, , ), соответствующий правилу. Сравнение — регистронезависимо.

  • : задаёт PHP колбек, который вызывается для определения, что правило должно быть применено.

  • : задаёт PHP колбек, который будет вызван, если доступ будет запрещён при вызове этого правила.

Ниже показан пример, показывающий использование опции , которая позволяет писать произвольную логику проверки доступа:

Пробуем ¶

Вот так просто мы и создали RESTful API для доступа к данным пользователя. API нашего сервиса сейчас включает в себя:

  • : получение постранично списка всех пользователей;
  • : получение метаданных листинга пользователей;
  • : создание нового пользователя;
  • : получение информации по конкретному пользователю с id равным 123;
  • : получение метаданных по конкретному пользователю с id равным 123;
  • и : изменение информации по пользователю с id равным 123;
  • : удаление пользователя с id равным 123;
  • : получение поддерживаемых методов, по которым можно обратится к ;
  • : получение поддерживаемых методов, по которым можно обратится к .

Пробуем получить ответы по API используя :

Попробуйте изменить заголовок допустимого формата ресурса на и в ответ вы получите результат в формате XML:

Если внимательно посмотреть результат ответа, то можно обнаружить, что в заголовках есть информация об общем числе записей, количестве страниц и т. д. Тут так же можно обнаружить ссылки на другие страницы, как, например, . Перейдя по ней можно получить вторую страницу данных пользователей.

Первое знакомство

Запуск приложения

Установленный шаблон уже содержит простой пример и несколько страничек. Работает простая авторизация пользователя администратора. В этом разделе показано на рисунке-схеме, как проходит запрос в приложении. Так что изучайте, ознакамливайтесь.

Говорим «привет»

Здесь показано как создать страницу с надписью «привет». Учимся создавать действие контроллера и представление.

Работа с формами

Работа с базами данных

Настраиваем подключение к БД. Определяем класс Active Record. Запрашиваем и отображаем данные.

Генерация кода при помощи Gii

Базовый код можно генерировать в Yii автоматически. Активируем Gii, создаём Active Record класс с помощью Gii. Генерируем код для реализации CRUD для таблиц БД. Настраиваем код, сгенерированный Gii.

Что дальше?

Изучайте документацию: подробное руководство, описание классов, вики-статьи и книги. Расширения. Сообщество.

Лучшие практические методики разработки моделей ¶


Модели являются центральным местом представления бизнес-данных, правил и логики. Они часто повторно используются в разных местах. В хорошо спроектированном приложении, модели, как правило, намного больше, чем контроллеры.

В целом, модели

  • могут содержать атрибуты для представления бизнес-данных;
  • могут содержать правила проверки для обеспечения целостности и достоверности данных;
  • могут содержать методы с реализацией бизнес-логики;
  • не следует напрямую задавать запрос на доступ, либо сессии, либо любые другие данные об окружающей среде. Эти данные должны быть введены контроллерами в модели;
  • следует избегать встраивания HTML или другого отображаемого кода — это лучше делать в видах;
  • избегайте слишком большого количества в одной модели.

Рекомендации выше обычно учитываются при разработке больших сложных систем. В таких системах, модели могут быть очень большими, в связи с тем, что они используются во многих местах и поэтому могут содержать множество наборов правил и бизнес-логики. Это часто заканчивается кошмаром при поддержании кода модели, поскольку одним касанием кода можно повлиять на несколько разных мест. Чтобы сделать код модели более легким в обслуживании, Вы можете предпринять следующую стратегию:

  • Определить набор базовых классов моделей, которые являются общими для разных приложений или модулей. Эти классы моделей должны содержать минимальный набор правил и логики, которые являются общими среди всех используемых приложений или модулей.
  • В каждом приложении или модуле в котором используется модель, определить конкретный класс модели (или классы моделей), отходящий от соответствующего базового класса модели. Конкретный класс модели должен содержать правила и логику, которые являются специфическими для данного приложения или модуля.

Например, в шаблоне приложения advanced, Вы можете определить базовым классом модели . Тогда для frontend приложения, Вы определяете и используете конкретный класс модели , который расширяется от . И аналогичным образом для backend приложения, Вы определяете . С помощью такой стратегии, можно быть уверенным, что код в используется только для конкретного frontend приложения, и если делаются любые изменения в нём, то не нужно беспокоиться, что изменения могут сломать backend приложение.

Контроллеры

Представления

Found a typo or you think this page needs improvement?Edit it on github !

Работа с файлами cookie ¶

Хотя файлы cookie и передаются, как значения заголовков, yii\httpclient\Request и yii\httpclient\Request предоставляют отдельный интерфейс для работы с ними при помощи \yii\web\Cookie and \yii\web\CookieCollection.

Для указания файлов cookie запроса можно использовать методы или . А для получения уже определенных файлов cookie к качестве экземпляра \yii\web\CookieCollection можно использовать метод или свойство . Например:

После того, как у вас есть объект ответа, вы можете получить доступ ко всем файлам cookie ответов, используя метод или свойство :

Вы можете передать файлы cookie из объекта ответа в объект запроса, используя простое копирование. Например: предположим, что нам нужно изменить профиль пользователя в каком-либо веб-приложении, которое доступно только после входа в систему, поэтому сначала нам нужно войти в систему, после чего использовать созданную сессию для дальнейших действий:

Установка

Использование: Форматы данных

Рендеринг видов ¶

Вы можете рендерить виды в контроллерах, widgets, или из любого другого места, вызывая методы рендеринга видов. Методы вызываются приблизительно так, как это показано в примере ниже,

Рендеринг в контроллерах

Внутри контроллеров можно вызывать следующие методы рендеринга видов:

  • : рендерит и применяет к результату рендеринга.
  • : рендерит без шаблона.
  • : рендерит без шаблона, и добавляет все зарегистрированные JS/CSS скрипты и стили. Обычно этот метод применяется для рендеринга результата AJAX запроса.
  • : рендерит вид, заданный как путь к файлу или алиас.

Например,

Рендеринг в виджетах

Внутри виджетов, вы можете вызывать следующие методы для рендеринга видов.

  • : рендерит .
  • : рендерит вид, заданный как путь файла или алиас.

Например,

Рендеринг в видах

Вы можете рендерить вид внутри другого вида используя методы, которые предоставляет компонент вида:

  • : рендерит .
  • : рендерит и добавляет зарегистрированные JS/CSS скрипты и стили. Обычно используется для рендеринга результата AJAX запроса.
  • : рендерит вид, заданный как путь к файлу или алиас.

Например, следующий код рендерит файл вида, который находится в той же папке что и вид, который рендерится в текущий момент. Помните, что в виде — это компонент вида (а не контроллер, как это было в Yii1):

Рендеринг в других местах

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

Именованные виды

При рендеринге вида, вы можете указать нужный вид, используя как имя вида, так и путь к файлу/алиас. В большинстве случаев вы будете использовать первый вариант, т.к. он более нагляден и гибок. Мы называем виды, которые были вызваны с помощью сокращенного имени именованные виды.

Имя вида преобразуется в соответствующий ему путь файла в соответствии со следующими правилами:

  • Имя вида можно указывать без расширения. В таком случае в качестве расширения будет использоваться . К примеру, имя вида соответствует файлу .
  • Если имя вида начинается с двойного слеша , соответствующий ему путь будет . Т.е. вид будет искаться в . Например, будет преобразован в .
  • Если имя вида начинается с одинарного слеша , то вид будет искаться в текущего модуля . Если активного модуля на данный момент нет, будет использована папка видов приложения по умолчанию, т.е. вид будет искаться в , как в одном из примеров выше.
  • Если вид рендеринтся с помощью и контекст реализует интерфейс yii\base\ViewContextInterface, путь к виду образуется путем присоединения контекста к имени вида. В основном это применимо к видам, которые рендерятся из контроллеров и виджетов. Например, будет преобразован в если контекстом является контроллер .
  • Если вид рендерится из другого вида, папка, в которой находится текущий вид будет добавлена к пути вложенного вида. Например, будет преобразован в если он рендерится из вида .

В соответствии с вышесказанным, вызов в контроллере будет рендерить файл , а вызов в этом виде будет рендерить файл .

Доступ к данным из видов

Данные можно передавать в вид явно или подгружать их динамически, обращаясь к контексту из вида.

Передавая данные через второй параметр методов рендеринга вида, вы явно передаете данные в вид. Данные должны быть представлены как обычный массив: ключ-значение. При рендеринге вида, php вызывает встроенную функцию PHP на переданном массиве, чтобы переменные из массива «распаковались» в переменные вида. Например, следующий код в контроллере передаст две переменные виду : и .

Другой подход, подход контекстного доступа, извлекает данные из компонента вида или других объектов, доступных в виде (например через глобальный контейнер ). Внутри вида вы можете вызывать объект контроллера таким образом: (см пример снизу), и, таким образом, получить доступ к его свойствам и методам, например, как указано в примере, вы можете получить ID контроллера:

Явная передача данных в вид обычно более предпочтительна, т.к. она делает виды независимыми от контекста. Однако, у нее есть недостаток — необходимость каждый раз вручную строить массив данных, что может быть довольно утомительно и привести к ошибкам, если вид рендерится в разных местах.

Передача данных между видами

Компонент вида имеет свойство , которое вы можете использовать для обмена данными между видами.

Например, в виде вы можете указать текущий сегмент хлебных крошек с помощью следующего кода.

Затем, в , который также является видом, вы можете отобразить хлебные крошки используя данные, переданные через .

Создание контроллеров ¶

В Веб приложениях, контроллеры должны быть унаследованы от yii\web\Controller или его потомков. Аналогично для консольных приложений, контроллеры должны быть унаследованы от yii\console\Controller или его потомков. Следующий код определяет контроллер:

ID контроллеров

Обычно контроллер сделан таким образом, что он должен обрабатывать запросы, связанные с определенным ресурсом. Именно по этим причинам, ID контроллеров обычно являются существительные, ссылающиеся на ресурс, который они обрабатывают. Например, вы можете использовать в качестве ID контроллера, которые отвечает за обработку данных статей.

По-умолчанию, ID контроллеров должны содержать только следующие символы: Английские буквы в нижнем регистре, цифры, подчеркивания, тире и слэш. Например, оба и являются допустимыми ID контроллеров, в то время как , , не являются таковыми.

ID контроллеров также могут содержать префикс подпапки. Например, в часть является контроллером в подпапке в . Допустимыми символами для префиксов подпапок являются: Английские буквы в нижнем и верхнем регистре, символы подчеркивания и слэш, где слэш используется в качестве разграничителя для многовложенных подпапок (например ).

Правила наименования классов контроллеров

Названия классов контроллеров могут быть получены из ID контроллеров следующими способами:

Привести в верхний регистр первый символ в каждом слове, разделенном дефисами

Обратите внимание что, если ID контроллера содержит слэш, то данное правило распространяется только на часть после последнего слэша в ID контроллера; Убрать дефисы и заменить любой прямой слэш на обратный; Добавить суффикс ; Добавить в начало .. Ниже приведены несколько примеров, с учетом того, что имеет значение по умолчанию равное :

Ниже приведены несколько примеров, с учетом того, что имеет значение по умолчанию равное :

  • соответствует ;
  • соответствует ;
  • соответствует ;
  • соответствует .

Классы контроллеров должны быть автозагружаемыми. Именно по этой причине, в вышеприведенном примере, контроллер должен быть сохранен в файл, псевдоним которого ; в то время как контроллер должен находиться в файле .

Карта контроллеров

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

Вы можете сконфигурировать в следующим образом:

Контроллер по умолчанию

Каждое приложение имеет контроллер по умолчанию, указанный через свойство . Когда в запросе не указан , тогда будет использован маршрут указанный в данном свойстве. Для Веб приложений, это значение , в то время как для консольных приложений, это . Таким образом, если задан URL , это означает, что контроллер выполнит обработку запроса.

Вы можете изменить контроллер по умолчанию следующим образом в :

Массовое Присвоение #

Массовое присвоение — это удобный способ заполнения модели данными вводимыми пользователем с помощью одной строки кода. Он заполняет атрибуты модели путем присвоения входных данных непосредственно свойству . Следующие два куска кода эквивалентны, они оба пытаются присвоить данные из формы представленные конечными пользователями атрибутам модели . Ясно, что первый код гораздо чище и менее подвержен ошибкам, чем второй:

Безопасные Атрибуты

Массовое присвоение применяется только к так называемым безопасным атрибутам, которые являются атрибутами, перечисленными в в текущем сценарии модели. Например, если модель имеет следующий заданный сценарий, в данном случае это сценарий , то только и могут быть массово присвоены. Любые другие атрибуты останутся нетронутыми.

По умолчанию будет возвращать все сценарии и атрибуты найденные в , если не переопределить этот метод, атрибут будет считаться безопасным только в случае, если он участвует в любом из активных правил проверки.

По этой причине существует специальный валидатор с псевдонимом , он предоставляет возможность объявить атрибут безопасным без фактической его проверки. Например, следующие правила определяют, что оба атрибута и являются безопасными атрибутами.

Небезопасные атрибуты

Как сказано выше, метод служит двум целям: определения, какие атрибуты должны быть проверены, и определения, какие атрибуты являются безопасными (т.е. не требуют проверки). В некоторых случаях необходимо проверить атрибут не объявляя его безопасным. Вы можете сделать это с помощью префикса восклицательный знак в имени атрибута при объявлении его в как атрибут в следующем примере:

Когда модель будет присутствовать в сценарии , то все три эти атрибута будут проверены. Однако, только атрибуты и могут быть массово присвоены. Назначить входное значение атрибуту нужно явно следующим образом,

Основные принципы ¶

Есть два основных принципа безопасности, независимо от того, какое приложение разрабатывается:

  1. Фильтрация ввода.
  2. Экранирование вывода.

Фильтрация ввода

Фильтрация ввода означает, что входные данные никогда не должны считаться безопасными и вы всегда должны проверять, являются ли полученные данные допустимыми. Например, если мы знаем, что сортировка может быть осуществлена только по трём полям , и , и поле может передаваться через ввод пользователем, лучше проверить значение там, где мы его получили:

В Yii, вы, скорее всего, будете использовать валидацию форм, чтоб делать такие проверки.

Экранирование вывода

Экранирование вывода означает, что данные в зависимости от контекста должны экранироваться, например в контексте HTML вы должны экранировать , и похожие специальные символы. В контексте JavaScript или SQL будет другой набор символов. Так как ручное экранирование чревато ошибками, Yii предоставляет различные утилиты для экранирования в различных контекстах.


С этим читают