Дайвинг в Symfony 2

Фреймворки являются горячими темами в веб-индустрии и были в течение некоторого времени. Symfony — это обширный фреймворк PHP, который следует популярной парадигме MVC. Его кривая обучения, вероятно, немного круче, чем у конкурентов, таких как CodeIgniter. Не волнуйтесь, как только это произойдет на вас, вы почувствуете себя сильнее, чем когда-либо, и сможете разрабатывать фантастические приложения.

1. Требования

В этой статье вам придется использовать консольную программу. Мне лично нравится Git Bash, но любой подойдет. Вам также нужно будет установить curl для установки Composer.

Если вы являетесь пользователем Windows, вы можете получить все вышеперечисленное, установив Git для Windows, который доступен прямо здесь: Git downloads .

2. Что вы узнаете

В этой статье вы узнаете больше о:

Поток приложений Symfony
Установка Symfony 2.1 с помощью Composer
Файловая структура и пакеты Symfony
Консоль
Маршруты и контроллеры
Ответы
прут

3. Жизненный цикл Symfony

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

Запрос

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

Ядро

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

Контроллер

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

Ответ

Как и в случае обычного HTTP-запроса, запрос Symfony должен возвращать объект ответа.
Объект ответа может быть сформирован различными способами, например, с помощью заголовков.
Действие должно вернуть действительный объект ответа, иначе будет выдано исключение.

Итак, теперь у вас есть краткое введение в механику Symfony — теперь пришло время погрузиться в игру.

4. Установка через Composer

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

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

curl -s http://getcomposer.org/installer |

Проверьте, что установка работала, набрав:

php composer.phar

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

Теперь перейдем к установке Symfony. Замените your-folder на любое имя папки, которое вы хотите для своего проекта. Вы также можете заменить версию в конце любым вашим выбором. Я рекомендую проверить Packagist: Symfony Framework Standard Edition на последнюю стабильную версию.

php composer.phar create-project symphony/framework-standard-edition your-folder/ 2.1.4

Теперь вы должны увидеть, как Composer загружает зависимости в папку. Если ваша установка прошла успешно, перейдите по your-project.local/web/config.php — здесь Symfony расскажет вам об отсутствующих требованиях к серверу или о дополнительных расширениях, которые могут повысить производительность или упростить вашу разработку.

Когда вы включили обязательные и необязательные расширения, перейдите в /web/app_dev.php где вы должны увидеть экран приветствия со ссылками на различные учебные материалы. Это означает, что Symfony был успешно установлен — поздравляю!

5. Введение в файловую структуру и пакеты Symfony

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

app/
src/
vendor/
web/

Каталог приложений

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

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

Ваш базовый HTML-макет также находится здесь.

Справочник Src

В каталоге src находится весь ваш собственный код, который сгруппирован в пакеты.

Кто или что такое пакет?

Весь код Symfony логически сгруппирован в так называемые пакеты. Например, скажем, ваш проект имеет пользовательскую систему, тогда все ваши пользовательские контроллеры, CSS, JavaScript, объекты базы данных и т. Д. Будут содержаться в UserBundle. Что хорошо в этой системе, так это то, что вы можете взять пакет (например, пакет управления пользователями) и подключить его к любому проекту Symfony.

Вы даже можете загрузить готовые пакеты с веб-сайтов, таких как KNP Bundles . Среди популярных вариантов — комплекты пользовательских систем и комплекты генераторов CRUD администрирования. На момент написания этой статьи на сайте было 1779 пакетов и 4068 разработчиков.

Справочник Продавца

Здесь мы будем хранить все сторонние библиотеки. Это уже заполнено библиотеками, например Symfony, Doctrine, Assetic и другими.

Веб-каталог

Это должен быть корневой каталог вашего домена, потому что это единственный общедоступный каталог вашего проекта. Здесь app_dev.php файлы app.php и app_dev.php фронт-контроллеров, которые являются двумя app_dev.php точками доступа к вашему приложению. Пользователь будет входить на ваш сайт через URL, например /app.php/products/jeans .

app_dev.php является основной точкой входа при разработке вашего приложения. Когда вы используете это как точку входа, Symfony пропустит кэширование и предоставит вам отличную панель инструментов разработки.
app.php является точкой входа для производственного режима. Это фактически делается необязательным с помощью mod_rewrite , поэтому URL-адреса /app.php/products/jeans и /products/jeans фактически указывают на одно и то же местоположение.

6. Кодирование с помощью консоли … Подождите, что?

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

Для меня одной из (удивительно) странных вещей при переходе на Symfony было интенсивное использование консоли.

Давайте просто погрузимся прямо в это. Откройте консоль и найдите корень проекта. Введите эту команду:

php app/console

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

7. Достаточно поговорить. Я хочу код!

Обладая базовыми знаниями о структуре и консоли, теперь вы готовы погрузиться в Symfony!

Перейдите в app_dev.php . Экран приветствия, который вы видите здесь, на самом деле является пакетом, похожим на тот, который мы создадим за минуту. Перейдите в src/ и удалите каталог Acme . Если вы обновите страницу, вы увидите ошибку. Это потому, что класс AppKernel пытается загрузить пакет, который мы только что удалили. Каждый раз, когда вы добавляете или удаляете пакет, вам нужно будет редактировать класс AppKernel .

Итак, откройте app/AppKernel.php . Вы увидите массив примерно так:

$bundles = array(
    new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
    // … Other bundles here
);

Здесь вы будете инициализировать новые пакеты. Если вы создаете пакет через консоль, он будет добавлен автоматически.

Далее вы должны увидеть блок if, подобный этому:

if (in_array($this->getEnvironment(), array(‘dev’, ‘test’))) {
    $bundles[] = new Acme\DemoBundle\AcmeDemoBundle();
    // … Other bundles here
}

Это пакеты разработки, то есть пакеты, которые загружаются только тогда, когда вы находитесь в среде разработки (app_dev.php). Вы увидите, что именно здесь инициализируется наш удаленный пакет. Удалите строку AcmeDemoBundle и сохраните файл.

Если вы обновитесь, теперь вы увидите страницу исключений Symfony. Здесь все перехваченные исключения будут перенаправлять вас и отображать больше информации. Вы увидите исключение, которое выглядит примерно так:

Cannot import resource «@AcmeDemoBundle/Controller/SecuredController.php» …

Это потому, что Symfony ищет определенные маршруты в файле контроллера SecuredController.php (который был в удаленном AcmeDemoBundle).

Так что же такое маршрут?

Вероятно, сейчас самое время объяснить немного больше о маршрутах. По сути, маршрут — это URL-шаблон. Представьте, что у вас есть блог с сообщениями по различным категориям. Таким образом, вы хотите, чтобы пользователь вводил в URL что-то вроде этого:

www.myblog.com/categories/Category1
www.myblog.com/categories/Category2
and so forth…

В Symfony вы можете определить URL-шаблоны, которые вам соответствуют контроллеру. Представьте себе предыдущий пример. Вам понадобится функция, которая получила имя категории и искала сообщения в блоге, используя ее. В приложении MVC и, следовательно, в Symfony эта функция помещается в контроллер. Так что в основном это будет выглядеть так:

class ControllerExample {
    public function showCategory($category_name) {
        // Pull out blog posts by category name and display them
    }
}

Примечание: это не правильный код Symfony, а просто пример простого контроллера блога.

Теперь вам просто нужно связать действие контроллера и URL. Это делается маршрутами. Маршрут в этом случае будет выглядеть так:

/categories/{name}

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

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

php app/console router:debug

Но помните, у нас была ошибка. Это потому, что Symfony все еще ищет определенные маршруты в нашем контроллере AcmeDemoBundle (который не существует). Итак, откройте app/config/routing_dev.yml и пока все, что вам нужно знать, это то, что все маршруты определены или импортированы в routing.yml и routing_dev.yml . Удалите ключи _demo_secured , _welcome и _demo_secured . Если вы обновитесь, теперь вы увидите, что не найден маршрут для «GET /» . Это связано с тем, что нет маршрутов, соответствующих текущему URL, поэтому давайте создадим тот, который соответствует.

Но во-первых, контроллер

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

Откройте консоль и введите следующую команду:

php app/console generate:bundle

Сначала вы должны ввести пространство имен вашего пакета. Общий шаблон для этого:

Vendor/BundleName

Продавец является автором пакета. Здесь вы можете указать название своей компании или что угодно. Мне нравится использовать мои инициалы EP. Используйте то, что вы хотите, но держите это коротким.

Название пакета должно заканчиваться на Bundle. Поэтому я введу следующее:

EP/BlogBundle

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

Теперь откройте src/YourVendorName/BlogBundle/ в вашем редакторе. Вы увидите, что базовая структура комплекта была создана для вас. Прямо сейчас мы пропустим детали и направимся прямо к каталогу контроллера. Откройте DefaultController.php в контроллере /.

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

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

/**
* @Route(«/hello/{name}»)
* @Template()
*/

Аннотация @Route сообщает Symfony, что мы хотим сопоставить маршрут /hello/{name} с действием \EP\BlogBundle\Controller\DefaultController::indexAction() и что в URL есть переменная с именем name . Так что, если кто-то вводит URL-адреса, подобные этим:

www.myblog.com/hello/Esben
www.myblog.com/hello/Santa
www.myblog.com/hello/Jesus

… они все пойдут в одно и то же место, потому что все они будут сопоставлены с маршрутом /hello/{name} .

Аннотация @Template сообщает Symfony, какой View использовать. Если оставить пустым, Symfony будет угадывать, какое представление использовать, основываясь на имени контроллера и имени действия.

Но не должны ли все действия возвращать действительный объект ответа?

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

Ответ — это объект, который содержит код, который вы хотите отобразить, служебные коды, заголовки и т. Д. Например, если вы хотите отобразить страницу «Hello World», вы сделаете что-то вроде этого:

return new Response(‘Hello World!’,200);

Если вы хотите создать страницу для вызова AJAX, это можно сделать так:

return new Response(json_encode(array(‘some_variable’=>’some value’)),200,array(‘content-type’=>’application/json’));

Если вы хотите перенаправить пользователя, вы можете сделать это с помощью объекта RedirectResponse .

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

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

return $this->container->get(‘templating’)->renderResponse(‘EPBlogBundle:Default:index.html.twig’,array(‘name’=>$name));

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

return $this->render(‘EPBlogBundle:Default:index.html.twig’,array(‘name’=>$name));

Это просто ярлык для первого метода, который я показал выше. Первый параметр — это представление для отображения. Все наши взгляды находятся внутри нашего пакета в Resources/views/ . Представления разделены на каталоги на основе контроллера, ответственного за представление. Отсюда и соглашение об именах Bundle: Controller: View .

Базовый вид вашего макета (основной шаблон вашего приложения) находится в app/Resources/views/ . Поскольку его нет ни в каком Bundle, ни в каталоге Controller, его просто называют ::base.html.twig . Представление в вашем пакете, которое находится в корневом каталоге bundle-views, называется Bundle :: View.

app/Resources/views/base.html.twig // ::base.html.twig
src/BlogBundle/Resources/views/someView.html.twig // EPBlogBundle::someView.html.twig
src/BlogBundle/Resources/views/Default/index.html.twig // EPBlogBundle:Default:index.html.twig

И, наконец, вторым параметром нашей функции render() являются переменные, которые нам нужны в нашем представлении.

Шаблон с веткой

Twig — это шаблонизатор, созданный Sensiolabs — создателями Symfony. Symfony поставляется в комплекте с Twig, хотя использовать его не обязательно.

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

Если вы откроете EPBlogBundle:Default:index.html.twig вы увидите код, который выглядит следующим образом:

Hello {{ name }}!

Twig использует {{ }} и {% %} качестве начального и конечного тегов. Двойные фигурные скобки означают вывод чего-то, похожего на PHP-эквивалент , Поэтому {{ name }} означает вывод значения нашей переменной $name (которое мы сказали Symfony, что хотели использовать при создании объекта ответа).


  Чтобы дать вам небольшой пример удивительности Twig, я покажу вам несколько фильтров.  Фильтр — это функция, которую вы можете применить к переменной.  Он применяется с использованием этого синтаксиса {{ var|filter }} .  Вот несколько примеров. 






1
2
3



{{ name|upper }} // returns the variable in UPPERCASE
{{ name|length }} // returns the length of the variable
{{ name|url_encode }} // returns the URL encoded version of the variable







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

  Вывод 
  Это конец нашего великолепного путешествия — и какое приключение! 
  Мы узнали не только о структуре Symfony и ее пакетах, но и о возможностях маршрутов и их контроллеров.  Посыпьте это немного веточкой, и вы познакомились с Symfony!  Вскоре я вернусь с более подробными руководствами по более конкретным темам, таким как управление активами в Assetic и шаблоны с Twig.  Спасибо за прочтение.



														
									
        Share: